Question to the use of "SPECIAL"

[helmut.brandl]

Is it possible in EiffelStudio / FreeELKS to inherit from SPECIAL?

Since SPECIAL is frozen, I asume that conformant inheritance is not
allowed. But nonconformant inheritance shall be possible (at least
according to the Eiffel standard).

The reason for asking this seemingly sophisticated question is to make
tecomp as compatible as possible to FreeELKS/EiffelStudio. Since the
standard does not give a clear answer, I thought I better ask reality
than theory.

Regards
Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault-4]

Helmut Brandl wrote:

> Is it possible in EiffelStudio / FreeELKS to inherit from SPECIAL?
>
> Since SPECIAL is frozen, I asume that conformant inheritance is not
> allowed. But nonconformant inheritance shall be possible (at least
> according to the Eiffel standard).
>
> The reason for asking this seemingly sophisticated question is to make
> tecomp as compatible as possible to FreeELKS/EiffelStudio. Since the
> standard does not give a clear answer, I thought I better ask reality
> than theory.

I shared the same point of view about theory. In fact in my opinion
SPECIAL should not be frozen. But as far as I know (Manu will need
to confirm) there is a implementation issue that prevents EiffelStudio
supporting inheritance from SPECIAL (even non-conforming). I hope
that this implementation issue will be addressed at some point.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault-3]

Helmut Brandl wrote:

> Is it possible in EiffelStudio / FreeELKS to inherit from SPECIAL?
>
> Since SPECIAL is frozen, I asume that conformant inheritance is not
> allowed. But nonconformant inheritance shall be possible (at least
> according to the Eiffel standard).
>
> The reason for asking this seemingly sophisticated question is to make
> tecomp as compatible as possible to FreeELKS/EiffelStudio. Since the
> standard does not give a clear answer, I thought I better ask reality
> than theory.

I shared the same point of view about theory. In fact in my opinion
SPECIAL should not be frozen. But as far as I know (Manu will need
to confirm) there is a implementation issue that prevents EiffelStudio
supporting inheritance from SPECIAL (even non-conforming). I hope
that this implementation issue will be addressed at some point.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault-4]

Helmut Brandl wrote:

> do you allow inheritance from SPECIAL in your gobo eiffel compiler gec?
> SPECIAL seems to be a very special beast. You cannot infer the object
> size from the type. You have to defer allocation until you execute the
> creation procedure make in order to have access to the size. This
> implies that you have to use the special creation procedure for creation
> only (or you prevent allocation, if called on an already allocated
> SPECIAL). This seems to put restrictions on descendants which you have
> to verify in the compiler.
>
> What about your opinion and implementation strategy in gec?

Inheritance from SPECIAL is not currently allowed in gec because
it would break interoperability with EiffelStudio.

My implementation strategy is based on the fact that even though
we want the best possible implement for SPECIAL (as optimal and
compact as possible), we could be more forgiving for descendants
of SPECIAL. So internally, the object might look like that:

   +------------------+
   |extra attributes  |
   |introduced in the |
   |descendant class  |
   +------------------+
   |hidden reference  |
   |to a SPECIAL to   |
   |store the items   |
   +------------------+

It's up to the compiler to emit the correct code when built-in
features are applied to objects of type SPECIAL, or to instances
of descendant classes.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[helmut.brandl]

Eric Bezault wrote:

> My implementation strategy is based on the fact that even though
> we want the best possible implement for SPECIAL (as optimal and
> compact as possible), we could be more forgiving for descendants
> of SPECIAL. So internally, the object might look like that:
>
>   +------------------+
>   |extra attributes  |
>   |introduced in the |
>   |descendant class  |
>   +------------------+
>   |hidden reference  |
>   |to a SPECIAL to   |
>   |store the items   |
>   +------------------+
>
> It's up to the compiler to emit the correct code when built-in
> features are applied to objects of type SPECIAL, or to instances
> of descendant classes.
>

Clearly it is possible to do something like that. But that implies a lot
of special treatment by the compiler. And it breaks the basic philosophy
that an inherited object is fully "contained" within the descendant object.

Furthermore you have to consider a lot of things to make sure, that the
strategy does not have any negative impact.

The most straightforward and safest approach is to forbid inheritance
from SPECIAL. But that would make SPECIAL very "special" from a user
point of view. And it is at least theoretically unsatisfying, because
SPECIAL would be no longer a class like any other class (in Eiffel you
cannot express the disallowance for use as a parent, frozen only forbids
the use as a conforming parent).

However, practically speaking, there seems to be no real need to inherit
from SPECIAL ....

Regards
Helmut
The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault-4]

Helmut Brandl wrote:
> Clearly it is possible to do something like that. But that implies a lot
> of special treatment by the compiler. And it breaks the basic philosophy
> that an inherited object is fully "contained" within the descendant object.

Is this a C++ philosophy? In Eiffel we have principles, and
don't remember where such principle is stated in Eiffel.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Simon Hudon]

Sorry to interrupt but observing Eric's implementation suggestion I  
can't help but wonder what would be the benefit of inheriting from  
SPECIAL (instead of TO_SPECIAL or ARRAY) if we are to store a  
reference to (what I understand to be) an actual SPECIAL object.  
Doesn't that defeat the purpose of having an object of varying size  
while avoiding linking through references (for efficiency concerns,  
for example)?  Is there another reason why we would like to inherit  
from SPECIAL?

Thanks,

Simon Hudon

On 4-Sep-08, at 12:24 PM, Eric Bezault wrote:

> Helmut Brandl wrote:
>> Clearly it is possible to do something like that. But that implies  
>> a lot
>> of special treatment by the compiler. And it breaks the basic  
>> philosophy
>> that an inherited object is fully "contained" within the descendant  
>> object.
>
> Is this a C++ philosophy? In Eiffel we have principles, and
> don't remember where such principle is stated in Eiffel.
>
> --
> Eric Bezault
> mailto:[hidden email]
> http://www.gobosoft.com
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> freeelks-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freeelks-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault-4]

Simon Hudon wrote:
> Sorry to interrupt but observing Eric's implementation suggestion I  
> can't help but wonder what would be the benefit of inheriting from  
> SPECIAL (instead of TO_SPECIAL or ARRAY) if we are to store a  
> reference to (what I understand to be) an actual SPECIAL object.  
> Doesn't that defeat the purpose of having an object of varying size  
> while avoiding linking through references (for efficiency concerns,  
> for example)?  Is there another reason why we would like to inherit  
> from SPECIAL?

Just to avoid having special rules in the Eiffel language.
And also, one might want to use SPECIAL polymorphically
(pass an object of type MY_SPECIAL where a SPECIAL is
expected).

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[helmut.brandl]

Eric Bezault wrote:
> Helmut Brandl wrote:
>> Clearly it is possible to do something like that. But that implies a
>> lot of special treatment by the compiler. And it breaks the basic
>> philosophy that an inherited object is fully "contained" within the
>> descendant object.
>
> Is this a C++ philosophy? In Eiffel we have principles, and
> don't remember where such principle is stated in Eiffel.
>
You are right. My comment has not been spelled out well. From a
theoretical point of view, there is no such a thing as "containment".
The descendant just has to provide the inherited features.

My comment applies to the implementation. From my experience having a
lot of special treatments increases the probability of bugs or
unexpected behaviour. Since you can do a lot of things with inheritance
in Eiffel and having one type with a very special treatment if inherited
by another class might create a lot of consequences which are difficult
to analyze. I doubt whether the benefit from being able to inherit from
SPECIAL justifies the analysis work.

By the way: Your proposal seems to be nearly identical to inheriting
from TO_SPECIAL (well, not fully identical, because TO_SPECIAL does not
have all the features of SPECIAL).

Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Simon Hudon]

On 4-Sep-08, at 12:58 PM, Eric Bezault wrote:

> And also, one might want to use SPECIAL polymorphically
> (pass an object of type MY_SPECIAL where a SPECIAL is
> expected).

But this would be prevented by the fact that SPECIAL is frozen.  
Hence, using non conforming inheritance to subclass SPECIAL would not  
allow polymorphic behavior (as far as SPECIAL is concerned).

As for the elimination of special rules, I'm all for it if its only  
effect is to simplify the language.  But I wondering if it is worth  
the trouble.  Does it provide a better way of doing something or is it  
mostly a pit fall (like Java's direct attribute access)?  At first  
glance, I'd say it cannot be worse than direct access of attributes  
but it is at least redundant with the inheritance of TO_SPECIAL which  
would reduce the simplicity of using Eiffel.

Simon Hudon

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault-4]

Simon Hudon wrote:
> On 4-Sep-08, at 12:58 PM, Eric Bezault wrote:
>
>> And also, one might want to use SPECIAL polymorphically
>> (pass an object of type MY_SPECIAL where a SPECIAL is
>> expected).
>
> But this would be prevented by the fact that SPECIAL is frozen.  
> Hence, using non conforming inheritance to subclass SPECIAL would not  
> allow polymorphic behavior (as far as SPECIAL is concerned).

I would remove the fact that SPECIAL is frozen in the first
place. That's something I already wanted to do in the past:
be able to inherit from SPECIAL in order to add new features
(not necessarily attributes). At that time I didn't understand
why this would not be possible. In fact at that time there
was no 'frozen' keyword on classes. EiffelStudio would just
reject the code with no validity rule violation. Since then
'frozen' has been added, but I'm not convinced that this
is the right thing to do.

> As for the elimination of special rules, I'm all for it if its only  
> effect is to simplify the language.  But I wondering if it is worth  
> the trouble.

The trouble is just for the compiler writers. For the
benefit of the programmers. So it's a good thing.
Bertrand has been saying for a long time that the
burden should be put on compiler writers, not on
programmers.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[helmut.brandl]

Eric Bezault wrote:
> The trouble is just for the compiler writers. For the
> benefit of the programmers. So it's a good thing.
> Bertrand has been saying for a long time that the
> burden should be put on compiler writers, not on
> programmers.
>  
That is a good statement and in general I agree with it. Without that
mindset we would not have Eiffel.

But up to now, the goodies of Eiffel do not put too much burden on
compiler writers. I find it astonishing that implementing an Eiffel
compiler is that straightforward.

When encountering some difficult to implemented features of Eiffel I
have usually found a straightforward way of implementing them by
analyzing the features of Eiffel in depth.

But all solutions I have found up to now to implement inheritance from
the class SPECIAL horrified me by their complexity and by the potential
bugs introduced into the compiler. Therefore I tend to disallow
inheritance from SPECIAL (but that is just a developers refusal to
implement something ugly).

But sometimes seemingly difficult problems  are just a challenge to
think a little bit more .... and maybe round the corner there is a not
yet discovered strategy to implement inheritance from SPECIAL in a
straighforward manner ...

I was hoping that you could give me some ideas because you obviously
favor the possibility to inherit.

To be honest, from a language perspective, I agree with you.


Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel