Repeated Inheritance/Parent calls 
Author Message
 Repeated Inheritance/Parent calls

I wanted to relate a little story with the group.

Last week, as I was devouring various sources of Eiffel information, I
noticed that Direct Repeated Inheritance was listed by several sources as a
nice thing to have. Each time I saw it listed, I racked my brain trying to
come up with a case where it would be nice to have -- I could think of
none. So, I forgot about it and went on reading.

Today, I suddenly wondered how, if a redefined feature in class B (which is
derived from class A) wants to call its parent implementation as well as
doing its own thing, I could accomplish this in Eiffel. A quick search of
comp.lang.eiffel in www.dejanews.com turned up, you guessed it, Direct
Repeated Inheritance (i.e. derive from A twice, renaming the feature in
question for the parent, and redefining it for second, calling the renamed
parent feature from the redefined one).

Now it would seem to me that the need to call a parents implementation of a
particular feature from the derived feature would be quite common. The idea
being that "I want to do what the parent would do, plus a little tiny bit
more". This is reuse in action. Eiffel should have a much more elegant
solution to this problem than direct repeated inheritance, which simply
takes advantage of a general renaming mechanism (which in and of itself is
quite elegant).

Perhaps I find this need to call the parent implementation to be common
because I am coming from C++, where its used a lot. The C++ method for
doing this is flawed in that you must statically scope the call, i.e. you
must explicitly name the parent class in the call, i.e. CView::OnDraw(). If
the parent class name changes, the code must be edited.

Objective-C (and Smalltalk ?) has the keyword super (if memory serves me),
which you can send messages to and they will get to the parent class
regardless of the class name, etc.

As I start to code Eiffel, I wonder if perhaps the differences it brings
about in the way I think about objects and hierarchies, will obliviate the
need to call parent implementations for any given redefined features. But I
can't seriously believe this, because as I mentioned I see this as a major
piece of reusability -- and having to use direct repeated inheritance and
renaming seems a quite cumbersome (and non-intuitive) method to achieve
this common need.

If I were voting for new keywords to be added, I would vote for one to be
added for this purpose. The  poster whose article I originally read
suggested prefacing 'inherited' to the call, i.e.:

inherited foo;

I would prefer 'super' I suppose, or 'parent'.

Ron Forrester



Sat, 13 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

Quote:

> I wanted to relate a little story with the group.

> Last week, as I was devouring various sources of Eiffel information, I
> noticed that Direct Repeated Inheritance was listed by several sources as a
> nice thing to have. Each time I saw it listed, I racked my brain trying to
> come up with a case where it would be nice to have -- I could think of
> none. So, I forgot about it and went on reading.

> Today, I suddenly wondered how, if a redefined feature in class B (which is
> derived from class A) wants to call its parent implementation as well as
> doing its own thing, I could accomplish this in Eiffel. A quick search of
> comp.lang.eiffel in www.dejanews.com turned up, you guessed it, Direct
> Repeated Inheritance (i.e. derive from A twice, renaming the feature in
> question for the parent, and redefining it for second, calling the renamed
> parent feature from the redefined one).

> Now it would seem to me that the need to call a parents implementation of a
> particular feature from the derived feature would be quite common. The idea
> being that "I want to do what the parent would do, plus a little tiny bit
> more". This is reuse in action. Eiffel should have a much more elegant
> solution to this problem than direct repeated inheritance, which simply
> takes advantage of a general renaming mechanism (which in and of itself is
> quite elegant).

> Perhaps I find this need to call the parent implementation to be common
> because I am coming from C++, where its used a lot. The C++ method for
> doing this is flawed in that you must statically scope the call, i.e. you
> must explicitly name the parent class in the call, i.e. CView::OnDraw(). If
> the parent class name changes, the code must be edited.

> Objective-C (and smalltalk ?) has the keyword super (if memory serves me),
> which you can send messages to and they will get to the parent class
> regardless of the class name, etc.

> As I start to code Eiffel, I wonder if perhaps the differences it brings
> about in the way I think about objects and hierarchies, will obliviate the
> need to call parent implementations for any given redefined features. But I
> can't seriously believe this, because as I mentioned I see this as a major
> piece of reusability -- and having to use direct repeated inheritance and
> renaming seems a quite cumbersome (and non-intuitive) method to achieve
> this common need.

> If I were voting for new keywords to be added, I would vote for one to be
> added for this purpose. The  poster whose article I originally read
> suggested prefacing 'inherited' to the call, i.e.:

> inherited foo;

> I would prefer 'super' I suppose, or 'parent'.

If you read OOSC II you will find 'precursor' that does exactly this.
However, I'm not sure when the compilers will support this.

--

Nick



Sun, 14 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

This one keeps coming out of the woodwork every time I look at this
group...

Eiffel's inheritance is different. The feature section of a class *doesn't
know and doesn't care whether it has any parents or not*. Inheritance can
be seen as nothing more than a shorthand, pulling in a load of features
from somewhere so you don't have to type them out again. This gives you a
nice 'flat' class which helps conceptual integrity a little - you don't
have to know about a class's parents.

When you have multiple and repeated inheritance it gets a little difficult
in a class hierarchy to work out which 'foo' you meant when you ask for a
parent version, particularly when you have several parents all with a
particular 'foo' in them.

Even if that could be solved there is the other issue of further
specialisation by class that will inherit in the future from the class you
are writing now. If they decide to specialise 'foo', should your call to
'inherited foo' be dynamically dispatched to this new 'foo' or not? If you
do then you may get into lovely recursion loops you weren't expecting and
if you don't you risk the horrors of static dispatch - including having to
re-write all the class hierarchy to make it work properly.

I'll admit that the 'Call parent' syntax is very long winded and believe me
many hours have been spent trying to devise a better solution. AFAIK none
has been found yet and the typing problem can easily be reduced by writing
a macro in your favourite text editor.

--

Aldur Systems Ltd, UK



Quote:
> Now it would seem to me that the need to call a parents implementation of
a
> particular feature from the derived feature would be quite common. The
idea
> being that "I want to do what the parent would do, plus a little tiny bit
> more". This is reuse in action. Eiffel should have a much more elegant
> solution to this problem than direct repeated inheritance, which simply
> takes advantage of a general renaming mechanism (which in and of itself
is
> quite elegant).



Sun, 14 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

Quote:

> If you read OOSC II you will find 'precursor' that does exactly this.
> However, I'm not sure when the compilers will support this.

`Precursor' will be part of ISE Eiffel version 4.2, scheduled to
be released at the time of TOOLS USA (28-31 July).

--
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)

Web: http://www.eiffel.com, with instructions for free download
== ISE Eiffel 4: Eiffel straight from those who invented it ==



Sun, 14 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

The detailed explanation and rationale for the Precursor
construct are in "Object-Oriented Software Construction,
second edition".

A couple of months ago I submitted a draft formal proposal
to the NICE language committee. Since the matter was
just raised on comp.lang.eiffel I have put a copy of this
proposal on our Web page at

        http://www.eiffel.com/doc/manuals/technology/precursor/

(I thought of posting it on the newsgroup but the formatting
does not work out well.)

Note that the language construct is extremely simple.
The proposal, on the other hand, is long and boring
because it has to explain the impact on other language
mechanisms and, page by page, the precise
changes to be made in the specification given by
the book "Eiffel: The Language". It is meant for
language experts (specifically, members of the language
committee of NICE). For language users the OOSC-2 explanations
should be more palatable.

A point of concrete syntax: careful readers of both OOSC-2
and the proposal will note the hesitation between
double and single braces. Single braces are simpler
and clearer, but ISE's implementation will accept both
forms. (I am the one responsible for the hesitation.)

As noted in the document the design of this mechanism
was a collective effort and any credit must be shared.
I am responsible for any error or deficiency in
the final result and the document.

--
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)



Sun, 14 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

Quote:

> The detailed explanation and rationale for the Precursor
> construct are in "Object-Oriented Software Construction,
> second edition".

Let me just mention to everybody the solution I have in mind, which
solves the problem - of reusing an ancestor's routine - and also
opens the door to other powerful Eiffel constructs.

The idea is to introduce static calls, i.e. let you bypass the multiple
dispatch mechanism.

I use the '~' in lieu of the '.' as a notation:

        a: A
        ...
        -- Call the version of "f from A" from the dynamic type of `a':
                a.f
        -- Call "f from A" whatever the dynamic type of `a':
                a~f

Now, if B inherits A and redefines f, you could use in B:

        a: A
                a := Current
                a~f

The effect is the same as calling {B}Precursor f, but no new keyword, no
curly brace, no class name where it doesn't belong are introduced.

Just take a look at the 'standard_*' routines in GENERAL, used in ARRAY,
to see how such a mechanism would also clean up some code.

Just in case compilers would not be as smart as we wanted them to be,
we could even tell them how to make calls faster (I might be getting
too practical here).

Comments? Flames?

-- PS



Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

Quote:

> Let me just mention to everybody the solution I have in mind, which
> solves the problem - of reusing an ancestor's routine

Thanks for posting your suggestion - it's always nice to be discussing
Eiffel in this newsgroup instead of Java and C++ and Mr Ousterhout!

The "precursor" proposal has been fairly widely discussed (by private email),
and the general consensus is that it caters for all situations where an
ancestor's implementation is to be reused. Although your suggestion is
more general, I don't think it provides a better solution to this
specific problem. (I agree with you that it would have further application
beyond this problem.)

Quote:
> ... a~f

> The effect is the same as calling {B}Precursor f, but no new keyword, no
> curly brace, no class name where it doesn't belong are introduced.

I can't see why people care so much about keyword counts - it's the
semantic complexity of a language that matters, and semantic complexity has
only a very weak correlation with keyword count. Specifically, a new symbol
(~) is no more desirable than a new keyword from a language complexity point
of view.

You are not the only person who has suggested that class names don't
belong in routine bodies, but I cannot understand this argument. We
have (since Eiffel 3) had class names in routine bodies for creation
features:

  !SOME_TYPE!some_entity

I've don't know of any problems caused by this.

Even if I accepted that class names didn't belong in routine bodies, I
would be equally unable to accept the introduction of
extra entities purely for the sake of their type information. Why not
be honest and open about it and just name the class explicitly?

[I'm similarly very uneasy about the routine 'fitted' in the Catcalls
proposal, where the routine argument is supplied for its type information
rather than its state.]

Personally, I believe the "precursor" proposal is a good solution to a
demonstrated problem, and would like to see it accepted by NICE.

Regards,
Roger

PS: Does anyone have any ideas for an alternative keyword? I am a little
uneasy that "precursor" might frighten away some of those who already
perceive Eiffel as being an academic rather than practical language.
[Delphi uses "inherited", Smalltalk uses "super" for similar constructs.]
--
--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525
-- Everything Eiffel: http://www.eiffel.demon.co.uk/ | +44-1772-687525



Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls



Quote:
> PS: Does anyone have any ideas for an alternative keyword? I am a little
> uneasy that "precursor" might frighten away some of those who already
> perceive Eiffel as being an academic rather than practical language.
> [Delphi uses "inherited", Smalltalk uses "super" for similar constructs.]

'Precursor' is the name in the literature for the list of features obtained
from parents. I'd prefer a name that is not used in other languages, just
to avoid connotations. It's a bit like the term 'feature' in that respect.

(I have to say the academic link is probably quite useful. I would imagine
it means the hacking fraternity leave Eiffel alone).

As another aside I think that there should be some consideration about
standardising on the way you refer to a class (or list of classes) in the
creation/feature sections. At the moment you have

feature {FRED}

!FRED!x.make

{{FRED}} precursor

Isn't it time to standardise?

   feature {FRED}

   {FRED}!! x.make

   {FRED} precursor

--

Aldur Systems Ltd, UK



Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

Quote:

> PS: Does anyone have any ideas for an alternative keyword? I am a little
> uneasy that "precursor" might frighten away some of those who already
> perceive Eiffel as being an academic rather than practical language.
> [Delphi uses "inherited", Smalltalk uses "super" for similar constructs.]

Ancestor

--

Nick



Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

Quote:
> The "precursor" proposal has been fairly widely discussed (by private email),
> and the general consensus is that it caters for all situations where an
> ancestor's implementation is to be reused. Although your suggestion is
> more general, I don't think it provides a better solution to this
> specific problem. (I agree with you that it would have further application
> beyond this problem.)

        I was hoping for an argument, as opposed to a mention of a general
consensus. Need I expand on what a general consensus can lead to? I wish
this
proposal to be argued rather than be quickly dismissed in some kind of
(appologies, no softer adjective) paternalistic way.

Quote:
> Specifically, a new symbol
> (~) is no more desirable than a new keyword from a language complexity point
> of view.

        Why not? I like "a - b" better than "minus (a, b)"

Quote:

> You are not the only person who has suggested that class names don't
> belong in routine bodies, but I cannot understand this argument. We
> have (since Eiffel 3) had class names in routine bodies for creation
> features:

>   !SOME_TYPE!some_entity

        Well, this is syntactic sugar for:

                some_type_object: SOME_TYPE
                ...
                !!some_type_object
                some_entity := some_type_object

        Which is what we had before (we actually had 'some_type_object.Create'
as opposed to '!!some_type_object')

        The language was slightly twisted here for the sake of programming
brevity.
In any case, it doesn't mean class names belong to routine bodies. We
just live
with this fine compromise, but one should not take it as a justification
for any
new exception.

Quote:
> Even if I accepted that class names didn't belong in routine bodies, I
> would be equally unable to accept the introduction of
> extra entities purely for the sake of their type information. Why not
> be honest and open about it and just name the class explicitly?

2 answers:

        1) Exactly. Let's declare variables honestly, as in: 'a: A', and not
need
any guesswork as with 'precursor f'

        2) When you program in Eiffel, you need to introduce extra entities
'for the
sake of their type information', to be viewed more positively as 'seeing
the
same object under another angle', as in:

        a: A
        a ?= retrieved -- from a database

        Some fine Eiffel programs will also use the fact that calls will not
execute
the same code depending on the static type of the variable, while just
one object will
be targetted by different entities.

Quote:
> Personally, I believe the "precursor" proposal is a good solution to a
> demonstrated problem, and would like to see it accepted by NICE.

        I know how hard it is to change one's mind, especially when an idea has
become
'a belief'. Please read some code you might have around, and just try
and use what I
suggest.

-- PS



Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

Quote:


>> I wanted to relate a little story with the group.

[..]

Quote:
>> Today, I suddenly wondered how, if a redefined feature in class B (which is
>> derived from class A) wants to call its parent implementation as well as
>> doing its own thing, I could accomplish this in Eiffel. A quick search of
>> comp.lang.eiffel in www.dejanews.com turned up, you guessed it, Direct
>> Repeated Inheritance (i.e. derive from A twice, renaming the feature in
>> question for the parent, and redefining it for second, calling the renamed
>> parent feature from the redefined one).

>> Now it would seem to me that the need to call a parents implementation of a
>> particular feature from the derived feature would be quite common. The idea
>> being that "I want to do what the parent would do, plus a little tiny bit
>> more". This is reuse in action. Eiffel should have a much more elegant
>> solution to this problem than direct repeated inheritance, which simply
>> takes advantage of a general renaming mechanism (which in and of itself is
>> quite elegant).

[..]

Quote:

>If you read OOSC II you will find 'precursor' that does exactly this.
>However, I'm not sure when the compilers will support this.

The standards body for Eiffel is a group called NICE (Nonprofit
International Consortium for Eiffel). The 'precursor' proposal is
before the Language Committee as we speak. Of course, just 'cause
the Committee's considering it is no _guarantee_ of passage, but
I do believe everyone on the Committee agrees there should be a
simpler mechanism than repeated inheritance for handling the quite
common situation described by the original poster.

Quote:

>--

>Nick

Hope this helps,
-- Jim

--

*------------------------------------------------------------------------------*
Jim McKim  (860)-548-2458     Teachers affect eternity. They can never tell



Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls



Quote:
> Ancestor

Ancestor is definitely different to precursor in the Eiffel definition.


Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

Quote:

> I was hoping for an argument ... I wish this proposal to be argued rather
> than be quickly dismissed in some kind of (appologies, no softer adjective)
> paternalistic way.

Sorry if you thought it sounded paternalistic. I wasn't even attempting to
dismiss your suggestion (although I challenged two of your arguments),
because I know your suggestion is workable.

Quote:

> Personally, I believe the "precursor" proposal is a good solution to a
> demonstrated problem, and would like to see it accepted by NICE.

> I know how hard it is to change one's mind, especially when an idea has
> become 'a belief'. Please read some code you might have around, and just try
> and use what I suggest.

I think you misunderstood me. I did not say "The precursor proposal is a
better solution than yours". I did not say "The precursor proposal is my
preferred solution". Indeed, a solution that I have previously advocated was
much closer to yours than to the precursor solution. I have tried your
proposal on real code. I am happy that it works, and would be happy to use it
in my own software.

The "precursor" proposal may not be everyone's idea of the _best_ solution to
this problem - there is no consensus on that. But it's acceptable to almost
everyone, which makes it likely to be a viable language change.

Regards,
Roger
--
--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525
-- Everything Eiffel: http://www.eiffel.demon.co.uk/ | +44-1772-687525



Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls


Quote:
> > Comments? Flames?

Any time...

Quote:
> > Let me just mention to everybody the solution I have in mind, which
> > solves the problem - of reusing an ancestor's routine
> > [...]

> > ... a~f

> > The effect is the same as calling {B}Precursor f,
> > but no new keyword, no curly brace, no class name
> >where it doesn't belong are introduced

Actually the syntax is just

        Precursor

in most cases, no curly braces, no class name. The routine
`f' is NEVER named, as this construct can only appear in
the redefinition of a routine, so there is no ambiguity
and no need to name the routine. `Precursor' means
"the original version (the ``precursor'', a term defined
precisely in``Eiffel: The Language'') of the routine
I am redefining just now".

The braces  will appear only in the rare case in which the class
is redefining in one shot TWO merged routines from different
ancestors. Then the syntax is

        {A} Precursor

where A is the name of the parent whose version is being
used. Again, no feature name. I don't expect anyway this
case to account for more than 5% of uses of Precursor
(perhaps 10% in basic libraries such as EiffelBase).

I am uneasy about a construct such as a~f denoting static
binding, because if I understand properly it denotes a
call on the object attached to `a'. But the version of
the feature that is being called in a version from an
ancestor class, so it may very well fail to preserve
the invariant - and hence result in run-time disasters,
as explained next.

        (Disclaimer: I have only seen a short, informal
         description of the a~f construct, so my reservations
         about it may be based on a misunderstanding.
         If so, I will certainly be corrected. The theoretical
         analysis that follows is, I believe, correct and
         important, but as to its application to the a~f construct
         don't take my word for it.)

For example assume that in some hotel management software
the class CARD_GUEST (representing customers who use
a credit card to pay) inherits from GUEST. For a card
customer we may have the constraint that the card
must have been authorized; this may be expressed by
an invariant clause of the form

   invariant
      registered implies card_authorized (estimated_amount)

which in Eiffel is automatically added to any invariant
clause defined for the parent class GUEST. All the
routines of CARD_GUEST must preserve that invariant
clause (i.e. they may assume it when they
start, and on terminating they must ensure it again).
Of course the routines of GUEST are only obligated to
preserve the invariant clauses of GUEST, since the class
knows nothing about CARD_GUEST and its specific features
such as `card_authorized'.

The procedure `register', which takes care of registering
a hotel guest, may be redefined in CARD_GUEST from its version
in GUEST, to take into account the new constraint; the new
implementation may be something like

        register is
                        -- Register guest, if authorization OK.
                do
                        Precursor
                            -- This does what was done by the
                            -- original `register' for arbitrary guests.
                            -- It sets `registered' to True or False
                            -- according to its own criteria.

                        check_authorization (estimated_amount)
                        if not authorized then
                                registered := False
                        end
                end

This sounds like a pretty typical use of Precursor. (It also seems
pretty clear to me. No curly braces, no reference to other classes,
no new characters.)

The problem if we allow something like

        this_guest~register

anywhere in the code (if that is the intention of the mechanism),
is that if `this_guest' is attached to an object of type
CARD_GUEST we may, and probably will, end up with an inconsistent
object, representing a card customer that has been registered
(`registered' is true) even though no card authorization was
ever requested, let alone granted. This is a catastrophic
situation: objects that do not satisfy their own proclaimed
consistency constraint. (That such a situation can occur
is in my opinion one of the major reasons why static binding,
as supported by default in C++ and Delphi, is not the right
policy.)

Such catastrophes are precisely the kind of thing that Eiffel
is meant to  avoid; with dynamic binding, `this_guest.register'
is guaranteed to use the version defined for the appropriate class,
which preserves the appropriate invariant. (This matter is discussed
in detail, with other examples, in "Object-Oriented Software
Construction, 2nd edition" (pages 511-515: "A button by any
other name" and "The C++ approach to binding").)

This danger of creating inconsistent objects cannot follow from
the Precursor construct: because the Precursor vesion is only
called on the current object within the execution of a routine
on that object, the rest of the routine has all the
opportunities it needs to restore the invariant before the object
becomes visible again to the rest of the world. This is
the case with the redefined version of `register' above:
after calling `Precursor' we perform additional actions
to restore the specific invariant of CARD_GUEST.

        (More generally, only qualified calls of the form
        `a.f' need to preserve the invariant; an internal,
        unqualified call `f' does not have to. Again, this
        is discussed in detail in OOSC-2.)

If the construct a~f is to be permitted in a general context,
then it will carry the risk of creating inconsistent objects,
with no easy way to warn the programmer of the danger.

`Precursor' is more restrictive and addresses one specific problem
-- simplifying redefinitions that rely on the original version --
without violating the fundamental rules of O-O design.

Please correct me if the above analysis is based on a
misunderstanding.

--
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)

Web: http://www.eiffel.com



Mon, 15 Nov 1999 03:00:00 GMT  
 Repeated Inheritance/Parent calls

:PS: Does anyone have any ideas for an alternative keyword? I am a little
:uneasy that "precursor" might frighten away some of those who already
:perceive Eiffel as being an academic rather than practical language.
:[Delphi uses "inherited", Smalltalk uses "super" for similar constructs.]

I agree "Precursor" does sound a little stilted but has the advantage of
accurately conveying the intended meaning, is the right part of speech (noun),
and isn't likely to be wanted by anyone as an identifier.

"Inherited" sounds good except that it could sound like a boolean expression:
"Is <something> inherited?".

A couple of alternatives:

  - "Forerunner" - Also a noun but probably worse.

  - "Original"  

    I may prefer this over "Precursor". It's a concept one can readily relate
    to and offers a direct association when speaking of an original feature
    versus a redefined one: "Original" associates with the original version,
    "redefines" associates with the redefined version. Although it is an
    adjective, a precedent exists with "Current" (meaning "current object")
    and old (meaning "old expression").

    On the downside, it would be useful as an identifier and may be thought to
    mean the very first version defined.

I don't like "Ancestor" because it has connotations (to me, at least) of classes
rather than features.

Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



Tue, 16 Nov 1999 03:00:00 GMT  
 
 [ 50 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Repeated inheritance semantics too complicated to implement?

2. Question to repeated inheritance

3. A problem with repeated inheritance?

4. Is Repeated Inheritance necessary (was: The Components Market)

5. Current and replication (repeated inheritance)

6. Re. Is Repeated Inheritance necessary

7. question on repeated inheritance

8. Repeated Inheritance Problem

9. Repeated inheritance

10. Eiffel/S: repeated inheritance

11. Help - semantics of repeated inheritance

12. Eiffel Type Hole in Repeated Inheritance?

 

 
Powered by phpBB® Forum Software