Eiffel: Can I use `expanded SOME_DEFERRED_CLASS`?

Question

x: expanded SOME_DEFERRED_CLASS is impossible because:

1. A deferred class cannot be used for object instantiation.
2. An expanded type does not allow polymorphism.

Have I missed something, or am I right?

Answer 1

x: expanded A_CLASS is an obsolete syntax. It is no longer supported.

However expanded can be used in a class definition. In this case, as you cited, it is not possible to have both a deferred and an expanded class.

As a simple rule, it is possible to define a class with only one from the next list: expanded, deferred, separate, frozen.

If you whish "expand" an already existing implementation, you just need to create an expanded heir of this class. Take a look to the Eiffel's kernel library, you can find examples of this (e.g. INTEGER_32 - an expanded class - inherits of INTEGER_32_REF)

Answer 2

You are right. The reasoning can be rephrased as follows:

1. No type conforms directly to an expanded type.
2. If a type is expanded, it conforms only to itself. (From 1. There are more conformance rules but for expanded types they can involve only generic parameters at most.)
3. An entity of a particular type can be used only if it is properly set.
4. An entity of an expanded type can be used only if it is instantiated with an object of the same type. (From 2 and 3.)
5. A deferred type cannot be used for instantiation.
6. An entity of a deferred expanded type cannot be used. (From 4 and 5.)

So, even though technically it might be possible to allow for declaration of entities of a deferred expanded type, they could not be used.

As correctly pointed out in the other answer, in the modern Eiffel, only one class mark can be used to indicate its status, and therefore, it's syntactically impossible to declare a deferred expanded class or type. However, even it were allowed, it would be useless.

EDIT:

There are two kinds of conformance: direct and general. Direct conformance reflects parent-child relationship: there are no transitivity or reflexivity rules, a special rule for the type NONE, etc. It basically states, that if a class C inherits from a class P, then the type C conforms to the type P under certain conditions. The conditions rule out the case when C is expanded.

General conformance uses direct conformance as one of the base cases together with some others, e.g. a reflexivity rule "a type conforms to itself". Therefore, the rule "no type directly conforms to an expanded type" simply means inheritance links do not matter for expanded types. But due to the reflexivity rule an expanded type still conforms to itself.

All these details behind the note "From 1". More information can be found in the Standard ECMA-367 (section 8.14).