Underused expanded types

Using expanded types for enumerations or aliased type names:

expanded class MY_ENUMERATION convert value: {INTEGER_32} feature make (value_a: INTEGER_32) do value := value_a end feature value: INTEGER_32 end

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:

expanded class MY_CONSTANTS feature red: INTEGER_32 = 1 blue: INTEGER_32 = 2 green: INTEGER_32 = 3 end

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:

feature constants: MY_CONSTANTS test local constants_2: MY_CONSTANTS do if constants.blue = constants_2.blue then io.put_string ("The same") end end

This is an alternative to using inheritance to pull in constants.

A small modification on the above to provide functions

expanded class NATURAL_32_FACILITIES feature rotate_right (value: NATURAL_32; count: INTEGER_32): NATURAL_32 do Result := (value |>> count).bit_or (value |<< (32 - count)) end end

These facilities can be used like:

feature rotation: NATURAL_32_FACILITIES test local rotation_2: NATURAL_32_FACILITIES do if rotation.rotate_right (0x3, 1) = rotation_2.rotate_right (0x6, 2) then io.put_string ("Successful") end end

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:

div (unsigned n, unsigned d, unsigned * q, unsigned * r)

By translating the output variables in to an ADT and making the routine a creation procedure you get an Eiffel equivalent:

expanded class DIVISION_RESULT feature make (n: NATURAL_32; d: NATURAL_32) do --... end q: NATURAL_32 r: NATURAL_32 end

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.