Underused expanded types
Using expanded types for enumerations or aliased type names:
It's as simple as that. Pass around MY_ENUMERATION and you have an efficient type that can be used like an enumeration or an aliased type name.
Using expanded types for constants:
The class MY_CONSTANTS has no members, so it has no size and therefore no state. It can be used in a local or as a class attribute such as the following:
This is an alternative to using inheritance to pull in constants.
A small modification on the above to provide functions
These facilities can be used like:
Expanded types can be used for output variables by creating an ADT out of the output variables. Take a division function that does a 2 machine word numerator and denominator and gives a 2 machine word quotient and remainder. A c-style way to represent this is:
By translating the output variables in to an ADT and making the routine a creation procedure you get an Eiffel equivalent:
In general if you have a C routine with input parameters pi_1 ... pi_j and output parameters po_1 ... po_j. Move parameters po_1 ... po_j in to attributes of your new expanded class E. Move the C routine in to E as a creation procedure taking in input parameters pi_1 ... pi_j and writing outputs to attributes of the expanded class.
Creation procedures on expanded types can be called statically by the compiler and static calls can be inlined. Using this expanded class ADT method, expanded classes can behave identically to C routines with output parameters when not inlined, or even C macros when the creation procedure is inlined.
Using this pattern allows one to have output parameters that are attached, via CAPs applied in the expanded type's creation procedures. Since this type is expanded it has a performance equivalent to output parameters.
Note: In the current Eiffel Studio compiler implementation, expanded types have a header which isn't really needed. This means expanded types have some size and initialization when they really shouldn't have to; this is an optimization that could be applied.
The current ECMA language specification requires a default_create procedure to be defined. This restriction could be loosened to be: "expanded types must have a default_create creation procedure, or be initialized on creation as class attributes" "expanded types must have a default_create creation procedure or be initialized prior to use as feature locals". This gives backwards compatibility to expanded objects created with default_create and doesn't force a default value of an expanded type which is restrictive especially in void-safe environments.