[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Liberty-eiffel Digest, Vol 53, Issue 9

From: Paolo Redælli
Subject: Re: Liberty-eiffel Digest, Vol 53, Issue 9
Date: Mon, 21 Feb 2022 11:52:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0

Il 21/02/22 00:44, Eric Bezault ha scritto:
Just to be clear, I'm not trying to "sell" you the notation specified
in ECMA for non-conforming inheritance. I just tried to explained
what it is and what lead to this design, without any assumption about
whether this notation is good or bad. Anyway, ECMA only specifies
'inherit {NONE}' in the standard, but not 'inherit {SOME_OTHER_CLASS}'.

Don't worry, I have truly appreciated your explanation. Over the years I remember I have asked here and there the same question elsewhere without receiving any reasonable answer.

Your instead not only is the first "real answer" on the matter but it's also "sound and solid" and suddenly explains, at least to me, why "inherit {NONE}" has been chosen.

Now I "only" have a couple of question.

First, as I never approached the question this way I have to understand where and how this "selective conformity" may be useful.

Secondly it seems not to be part of ECMA Eiffel, 2nd edition, at least from ; I also searched for founding

Both documents, the standard and the web page don't cite this "selective inheritance".

Selective inheritance seems a powerful abstraction - I dare say it could look magic to people used to using other languages -  but as far as I can say it has a lot of interactions with the other rules of the language.

It's a little mind-globbing, at least to me.

Personally I find the explantion of non conforming inheritance syntactically exact but a little hard to grasp:

Non-conforming inheritance allows features to be inherited from parent to heir, but it disallows polymorphic attachment of a direct instance of an heir to an entity based on a non-conforming parent.

I rather prefer the "non-conforming inheritance allows an object to have all the features of a class without being an instance of that class" or even more concise: "insert X" means "have all the features of X, but it is not an X". 

I also don't want to force "insert", but the dichotomy inherit/insert makes sense when conformity is a dichotomy, i.e. a class either conform or not to another, instead of selectively conform depending on where it is used.

The more I think about it the more "inherit {FOO}" seems to be a shapeshifting power :)

But I have not given it enough thought to get a clear idea on the matter.

Has this idea been discussed somewhere?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]