Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Exports in multiple inheritance - Who wins?

1 view
Skip to first unread message

llothar

unread,
Nov 23, 2009, 9:06:06 PM11/23/09
to
If i have two base classes with conforming export and a subclass

class S
inherit F1
export {STRING} print_me
undefine print_me
end
inherit F2
export {INTEGER} print_me
undefine print_me
end

Is print useable from STRING or INTEGER or from both classes or should
this throw an error ?

Eric Bezault

unread,
Nov 24, 2009, 2:43:05 AM11/24/09
to

According to ECMA 367-2, section 8.7.12, page 52, we take the union
of the clients. So it is exported to both STRING and INTEGER.

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

Helmut

unread,
Nov 24, 2009, 10:22:36 AM11/24/09
to

This is my understanding as well.

One interesting aspect. Under conformant inheritance a feature can
only win clients, never loose (i.e. cumulation of clients). This has
the advantage, that certain catcalls where a descendent hides a
feature are no longer possible in ECMA Eiffel. Descendant hiding is no
longer allowed under conformant inheritance. Non conformant
inheritance allows descendant hiding, but disallows polymorphic
attach.

Regards
Helmut

llothar

unread,
Nov 29, 2009, 12:31:20 PM11/29/09
to
On 24 Nov., 16:22, Helmut <helmut.bra...@gmx.net> wrote:

> > According to ECMA 367-2, section 8.7.12, page 52, we take the union
> > of the clients. So it is exported to both STRING and INTEGER.
>
> > --
> > Eric Bezault
> > mailto:er...@gobosoft.comhttp://www.gobosoft.com
>
> This is my understanding as well.

I'm not sure if this is okay. Both export client lists are
written explicitly and in the same text file so there is no reason
why the compiler should not force the user to write complete correct
exports.

So throwing an error looks like a better solution for me. It looks
much like autocorrection of an error. And based on my experience with
SmartEiffel this is the worst thing they have ever added to Eiffel.


> One interesting aspect. Under conformant inheritance a feature can
> only win clients, never loose (i.e. cumulation of clients).

I'm not so sure about this rule. Does ECMA really define it?
For me the client visibility is totally independent from the
inheritance/conforming hierarchy.

Helmut

unread,
Dec 2, 2009, 6:36:37 PM12/2/09
to
On Nov 29, 11:31 am, llothar <scholz.lot...@gmail.com> wrote:
> On 24 Nov., 16:22, Helmut <helmut.bra...@gmx.net> wrote:
>
> > > According to ECMA 367-2, section 8.7.12, page 52, we take the union
> > > of the clients. So it is exported to both STRING and INTEGER.
>
> > > --
> > > Eric Bezault
> > > mailto:er...@gobosoft.comhttp://www.gobosoft.com
>
>
> I'm not sure if this is okay. Both export client lists are
> written explicitly and in the same text file so there is no reason
> why the compiler should not force the user to write complete correct
> exports.
>
> So throwing an error looks like a better solution for me. It looks
> much like autocorrection of an error. And based on my experience with
> SmartEiffel this is the worst thing they have ever added to Eiffel.

According to pre ECMA Eiffel you are right. But ECMA changed the
semantics of the export clause under conformant inheritance. The basic
idea: With conformant inheritance exports are cumulative, i.e. in your
example above

> class S
> inherit F1
> export {STRING} print_me
> undefine print_me
> end
> inherit F2
> export {INTEGER} print_me
> undefine print_me
> end

the feature "print_me" has all the clients defined for "print_me" in
F1 plus all the clients from F2 plus {STRING,INTEGER}.

Therefore as I have said before, descendant hiding is no longer
possible with conformant inheritance. For non-conformant inheritance
the rules are different.

llothar

unread,
Dec 2, 2009, 8:55:47 PM12/2/09
to
> Therefore as I have said before, descendant hiding is no longer
> possible with conformant inheritance. For non-conformant inheritance
> the rules are different.

Wow, that will break a lot of code.

Looks like i have to print out Meyers new ETL book and study it.
The ECMA standard paper is a really dry read.

Martin Piskernig

unread,
Dec 3, 2009, 5:43:27 AM12/3/09
to
llothar wrote:
>> Therefore as I have said before, descendant hiding is no longer
>> possible with conformant inheritance. For non-conformant inheritance
>> the rules are different.
>
> Wow, that will break a lot of code.
>
> Looks like i have to print out Meyers new ETL book and study it.

Unfortunately the ETL3 book draft has not been updated since August 2005,
as far as I can see on the ETHZ homepage, so you will have to read the
standard (although it is outdated in some chapters like void-safety).

Martin

Emmanuel Stapf [ES]

unread,
Dec 3, 2009, 2:30:11 PM12/3/09
to
> According to pre ECMA Eiffel you are right. But ECMA changed the
> semantics of the export clause under conformant inheritance. The basic

This has always been the case in Eiffel, you take the union of exports.
What has changed in the ECMA Eiffel standard is that you cannot restrict
the export of an inherited routines, but that's for addressing the well
known A in CAT calls.

Regards,
Manu

Helmut

unread,
Dec 3, 2009, 4:17:02 PM12/3/09
to
On Dec 3, 1:30 pm, "Emmanuel Stapf [ES]"

If Eiffel had always taken the union of exports, it wouldn't be
possible to restrict the export of an inherited routine. Union means
all the clients of the parent *plus* the clients of the current class.

It is funny that you say that I am wrong and by the same token you say
the same what I have stated before.

Another remark: The standard is not only outdated with respect to void
safety. The chapters concerning covariant redefinition and catcalls
are obsolete as well. This seems to be the reason that it takes so
long to get an updated version.

Manu, you as a leading member of the ECMA committee might give us a
hint when to expect an updated version of the standard.

Regards
Helmut

llothar

unread,
Dec 3, 2009, 5:52:21 PM12/3/09
to
On 3 Dez., 22:17, Helmut <helmut.bra...@gmx.net> wrote:

> Manu, you as a leading member of the ECMA committee might give us a
> hint when to expect an updated version of the standard.

By the way, what are EiffelStudio users doing?

The website and help menu links to the very old OOSE book as the only
reference. Do you really expect that this is enough for users of a
5000$
tool?

Maybe you guys should really consider Guidos advice for Python.
Stop all language development for 5 years and fix the worst problems
first.

Most of what you discuss is so insane far away from users needs
its upsets me. You should really sit down and write 100 times:
"Programming languages features are not important" on your
commitee whiteboard.

And i see i agree more and more with the SmartEiffel teaam that
ECMA Eiffel is a failure and not Eiffel anymore and the death of
the language. The community is getting smaller and smaller, even
universities are moving away from teaching it in Software
engineering courses.

The ECMA standard is and was nothing more then a helpless
marketing idea. Remembers me of all the non finished standards
during the unix wars. But there it were different companies fighting.
Here the problems are homemade by crazy guys from one same company.

Take this rant as a hint from someone who was never wrong in the
past 8 years with any prediction of the future of eiffel and
public eiffel based projects.

clemahieu

unread,
Dec 4, 2009, 10:50:33 AM12/4/09
to
Do you even program in Eiffel or just read the specification and start
flamewars on unmoderated forums?

Helmut

unread,
Dec 4, 2009, 12:02:09 PM12/4/09
to
The ECMA Eiffel language specification is a well written document (it
is a language specification document and not a document for the Eiffel
user). It lacks only in the area of void safety, initialization and
covariant redefinitions (catcalls). The other chapters are well done.

The problem: It has not been updated since june 2006. I.e. it reflects
a status which has never been implemented (and will probably never be
implemented, not even by EiffelStudio).

Emmanuel Stapf [ES]

unread,
Dec 4, 2009, 2:25:12 PM12/4/09
to
Helmut wrote:
> If Eiffel had always taken the union of exports, it wouldn't be
> possible to restrict the export of an inherited routine. Union means
> all the clients of the parent *plus* the clients of the current class.

The question was about inheritance and what you do on merging two sets
of export clauses. Answer you take the union and there is no need to
discuss that point, it has always been like that for at least the past
15 years.

Restricting exports is when you give a new export list, either via
inheritance, or via redefinition in a give feature clause which has an
export clause.

Regards,
Manu

Helmut

unread,
Dec 4, 2009, 3:47:44 PM12/4/09
to
On Dec 4, 1:25 pm, "Emmanuel Stapf [ES]"

<manus_no_s...@eiffel.nospam.com> wrote:
> Helmut wrote:
> > If Eiffel had always taken the union of exports, it wouldn't be
> > possible to restrict the export of an inherited routine. Union means
> > all the clients of the parent *plus* the clients of the current class.
>
> The question was about inheritance and what you do on merging two sets
> of export clauses. Answer you take the union and there is no need to
> discuss that point, it has always been like that for at least the past
> 15 years.

Manu, we agree completely on the status as it is now. No need to
discuss that. But in the past it was different. Bertrands last book to
specify Eiffel (Eiffel - The Language, ETL2) stated that with

class OSTRICH inherit
BIRD export {NONE} fly end -- <---- "descendant hiding"
...
end

you replace the client list of "fly" inherited from BIRD with an empty
one. Union of client lists from the parent and the heir was not part
of ETL2 (maybe union of client lists of different inheritance
clauses). In ECMA Eiffel you cannot achieve that replacement of the
client list with conformant inheritance. You have to write instead

class OSTRICH inherit {NONE}
BIRD export {NONE} fly end
...
end

using non conformant inheritance. That is all what I have said.
Nothing more, nothing less. I don't know what you have read from my
post to feel the need to correct my statements. ETL2 is from 1992 and
is therefore more than 15 years old. Is there a specification of
Eiffel between ETL2 and ECMA which I am not aware of?

0 new messages