The Eiffel language mapping provides the ability to access and implement CORBA objects in programs written in the Eiffel language. Minimal requirements are placed on Eiffel implementations other than correct implementation of the language as specified in [ETL] and support of the Eiffel Library Standard Vintage 95 [ELS].
Every effort has been made not to limit the implementation freedom of ORB developers. The following definition of conformity allows ORB providers to offer added value services without foregoing OMG branding.
A client or object implementation is said to conform to this mapping if it uses the constructs as described here. A CORBA implementation is said to conform if it correctly executes any conforming client or object implementation, which are therefore portable across all conforming ORBs.
It follows that any application which uses extensions to this mapping does not conform, and hence is not necessarily portable to another ORB.
The semantics and usability of the mapping as seen by the application developer were considered of extreme importance. Every effort was made to ensure that the Eiffel language was used in a natural way.
It should be possible to take a system that has already been implemented and distribute one or more of the objects within it with the minimum of change to application code. One should be able to take the implementation (in Eiffel) of a CORBA object and embed it directly in client Eiffel code with little change. It would naturally be necessary to make new arrangements for the creation of the object and the passing of a reference to it to the client.
This proposal maps the entire language as defined in the Common Object Request Broker Architecture and Specification version 2.0, [Corba2.0]. The order has been changed from the C mapping where it is appropriate for clearer presentation, for example the mapping of any has to refer to the mappings of other types, and so appears later.
The following items are true for all the Eiffel classes mentioned in the document.
Where applicable, pre and post conditions (require and ensure) are used rather than requiring specific run time exceptions. This is consistent with accepted Eiffel practice, and enables the required level of diagnosability to be obtained without impairing the performance of a fully debugged system.
The proposed language mapping requires no extensions to CORBA. Some reference is made to proposals which are still in the pipeline, for example the ones on portability [POA]. The mapping is not dependent on these however, and will be updated to follow whatever is finally ratified by OMG.
The mapping is expressed entirely in terms of class interfaces. Possible implementations are discussed where this helps to clarify the mapping or its rationale, but these are not part of the proposed standard.
The proposed mapping has been designed with due consideration to the following Eiffel implementations:
Where requirements must be placed beyond those of published Eiffel standards ( [ETL], [ELS]), for example the minimum size of an Eiffel INTEGER, all implementations are already adequate.
Scoping details the mapping for identifiers. As explained there, due to the nature of the name spaces in Eiffel there are possible legal IDL specifications which will not yield compilable Eiffel code due to name collisions. The problem is similar to but less severe than the one suffered by the Smalltalk mapping. Each implementation must support an explicit naming mechanism which can be used to map an IDL identifier on to an arbitrary Eiffel class or feature name.
This mapping uses standard Eiffel constructs and classes that conform to the Eiffel Library Standard [ELS].
The following table summarizes the Eiffel mapping. Subsequent sections discuss each element in turn, identifying the key decisions supporting the strategy laid out in Aims.
|IDL Construct||Eiffel Construct|
|Attribute||``attribute'' and ``set_attribute'' features|
|Data types||Classes, either generated or drawn from the Eiffel Library Standard|
A cluster in Eiffel is a logical grouping of classes, usually mapped to an operating system facility such as a directory. Though it is not in fact an element of the language [3.1 (ETL)] it is a generally accepted part of the Eiffel method.
Clusters are not however a means of creating separate name spaces, though some compilers do provide the means to resolve name clashes between clusters.
The classes generated for different IDL modules may be placed in corresponding Eiffel clusters, but this standard does not require it. The cluster which corresponds to a source file with no module declarations is also implementation dependent.
For each IDL interface there are two kinds of object; the implementation and references to it. These are modeled by three classes.
The inheritance relationships present in the IDL are reflected in the supplied classes. This extends to base classes supplied by the implementation to correspond to the PIDL for CORBA::Object.
This is similar to the ADA [ADA] or Java [Java] mappings, though the details are more straightforward due to the purer object oriented nature of Eiffel, including support for multiple inheritance.
Operations are mapped to features with equivalent signatures. There is a one-to-one mapping from IDL parameters to Eiffel arguments.
The get operation is mapped to a feature of the same name as the IDL attribute, as Eiffel deliberately makes it invisible to the client as to whether a parameterless function is implemented as a routine or an attribute. The set operation is prefixed with set_ as suggested in the CORBA standard [3.11 Attribute Declaration (Corba2.0)] and in accordance with common Eiffel practice.
The IDL data types are mapped on to either Eiffel Library Standard classes or classes generated using these. This is done for three reasons:
Parameter passing is intended to be as natural as possible. In general one would expect to pass the same parameter types as would be used if the object implementation were a local one written in Eiffel. Write-back (out) parameters are therefore supported using ordinary Eiffel object references, so that parameter types only need to be different for those IDL types such as long which map on to expanded types in Eiffel. For interfaces it is necessary to use the reference class for write-back parameters, as discussed in Interfaces.
Compare this with the Smalltalk approach, [20.6 Invocation of Operations (Corba2.0)], and Java [Parameter passing modes (Java)], which both invent a container type for writable parameters.
Memory management is provided entirely by the Eiffel garbage collector. The interfaces defined for pseudo objects are modified to remove references to operations such as free.