Re: [freeelks-devel] make FreeELKS more ECMA compliant

[Emmanuel S. [ES] <ma...@ei...>]

> By the way: What kind of immutable aspect of STRING are you going to
> implement? It would be nice to read something about it before finding it
> as a fact in ELKS. Don't forget: STRING belongs to the inner kernel of
> Eiffel so I would really appreciate some discussion or at least
> explanation of the matter.

Look at Peter's email with the link to the prior discussion. For the moment, the
adopted simplified hierarchy is:

READABLE_STRING_GENERAL
^
|
READABLE_STRING_8    STRING_GENERAL
^                          ^
|                          |
STRING_8 -------------------

Same goes for the _32 variant. What we haven't done yet is writing the
IMMUTABLE_STRING variant mostly because we haven't really decided how. The current
thoughts are that if you do IMMUTABLE_STRING.substring, you get another
IMMUTABLE_STRING object but the `area' part is shared among the 2 IMMUTABLE_STRING
objects. The only drawback of this approach is let say that you start with an
IMMUTABLE_STRING of 2MB, then do a substring of 10 characters on it and the
original IMMUTABLE_STRING is not referenced anymore, then the 10 characters
IMMUTABLE_STRING still holds a reference to an area of 2MB which is maybe not
expected.

> Why does this break code? I can imagine 2 cases:
> 1. A class inherits from INTEGER or REAL and redefines (or renames, etc)
> infix "+".
> 
> 2. A class inherits from INTEGER etc. and in the inherited class you get
> naming conflicts with e.g. the feature plus (since in ECMA Eiffel every
> feature must have a normal name beside the alias).

We were not thinking about those cases which are indeed very rare, but about
COMARABLE. Many classes do inherit from it and this is what we would be breaking
if their specification was to use `alias'.
 
Regards,
Manu