Re: Extends is evil?

bluke wrote:

> What do smalltalkers think
> about implementation inheritance?


A characteristic of implementation inheritance
called "YO-YO effect" has been discussed in
OO literature already a long time ago. It's a
good thing the Java folks are catching up :-)

Yo-yo effect refers to the fact that in an
(implementation) inheritance hierarchy the
control jumps up and down, down and up etc.
This makes it that much more difficult to
understand what is going on.

Nevertheless most of us do use implementation
inheritance, for the benefits it brings.

One way to minimize problems and risks with
implementation inheritance is to use the BRIDGE
design pattern: Separate public methods and
private implementation methods into *separate*
hierarchies.

Thus BRIDGE is somewhat a middle path between
pure implementation inheritance and pure
delegation approaches.

Google: OO yo-yo effect objects ECOOP
-Panu Viljamaa

"Peter van Rooijen" <peter@vanrooijen.com> escribió en el mensaje
news:3f3407e0$0$49115$e4fe514c@news.xs4all.nl...
> "panu" <panu@fcc.net> wrote in message
> news:Se6dncTW1r_jQ6-iU-KYgw@fcc.net...
> > bluke wrote:
> >
> > > What do smalltalkers think
> > > about implementation inheritance?
>
> [snip]
>
> It seems that there is some confusion over what the term "implementation
> inheritance" actually means.
>
> Implementation inheritance refers to the situation where one class
inherits
> another, without a resonable subtyping relationship between the two.
>
> An example would be to think that a chess club is a set of people, and
> translating that into defining a class ChessClub that inherits Set.

Why? It has a set of people, why would that be a problem?

I think implementation inheritance is when a Dog is a Name, because instead
a Dog should have a Name. or a more real example: a Dog is a Cat that barks
instead of meows, so meow() calls bark().
>
> This is a mistake.
>
> And don't laugh at the example, I've seen code doing such things by
> programmers who were paid to write it (I've changed the example to protect
> the guilty ;-)).
>
> Regards,
>
> Peter van Rooijen
> Amsterdam
>
>

"Guillermo Schwarz" <guillermo_schwarz@hotmail.com> wrote in message
news:3f38e49d@news.totallyobjects.com...
> "Peter van Rooijen" <peter@vanrooijen.com> escribió en el mensaje
> news:3f3407e0$0$49115$e4fe514c@news.xs4all.nl...
> > "panu" <panu@fcc.net> wrote in message
> > news:Se6dncTW1r_jQ6-iU-KYgw@fcc.net...
> > > bluke wrote:
> > > > What do smalltalkers think
> > > > about implementation inheritance?
> >
> > [snip]
> >
> > It seems that there is some confusion over what the term "implementation
> > inheritance" actually means.
> >
> > Implementation inheritance refers to the situation where one class
> inherits
> > another, without a resonable subtyping relationship between the two.
> >
> > An example would be to think that a chess club is a set of people, and
> > translating that into defining a class ChessClub that inherits Set.
>
> Why? It has a set of people, why would that be a problem?

Guillermo,

That is a great question which has a great answer, which I am not going to
give you here :-).

> I think implementation inheritance is when a Dog is a Name, because
instead
> a Dog should have a Name.

That is also an example of "implementation inhertitance".

> or a more real example: a Dog is a Cat that barks
> instead of meows, so meow() calls bark().

I've never seen code with such classes, much less it being called a "real
example". Now I am sure you are kidding.

Regards,

Peter van Rooijen
Amsterdam

> > This is a mistake.
> >
> > And don't laugh at the example, I've seen code doing such things by
> > programmers who were paid to write it (I've changed the example to
protect
> > the guilty ;-)).

"Peter van Rooijen" <peter@vanrooijen.com> wrote in message news:<3f38f235$0$49110$e4fe514c@news.xs4all.nl>...
> "Guillermo Schwarz" <guillermo_schwarz@hotmail.com> wrote in message
> news:3f38e49d@news.totallyobjects.com...
[...]
> > or a more real example: a Dog is a Cat that barks
> > instead of meows, so meow() calls bark().
>
> I've never seen code with such classes, much less it being called a "real
> example". Now I am sure you are kidding.

How about OrderedCollection>>at:? Or Dictionary>>add: (if you think
that one's ok, you must instead have a complaint with
Dictionary>>select. Smalltalk has plenty of other meows and barks.
It gets by, but there are some truly ancient potholes that will never
be filled.

Guillermo Schwarz wrote:
>> An example would be to think that a chess club is a set of people, and
>> translating that into defining a class ChessClub that inherits Set.
>
> Why? It has a set of people, why would that be a problem?

The problem is that a ChessClub can only hold people; A Set can hold any
kind of object. So if I say to you, "Give me a Set, any set will do" and
you give me a ChessClub, it might not work. I *think* you gave me a type-of
Set, so I try to add some arbitrary objects to it (eg a bunch of integers
or strings). ChessClub only wants people.

The correct relationship is part-of. People are part-of a ChessClub in the
same way that an engine is part-of a car.

Implementation inheritance is just what it says: sharing code
(implementation) without preserving the kind-of or type-of relationship.

-anthony

Guillermo Schwarz <guillermo_schwarz@hotmail.com> wrote:

: "Peter van Rooijen" <peter@vanrooijen.com> escribi en el mensaje
:>
:> It seems that there is some confusion over what the term "implementation
:> inheritance" actually means.
:>
:> Implementation inheritance refers to the situation where one class
: inherits
:> another, without a resonable subtyping relationship between the two.
:>
:> An example would be to think that a chess club is a set of people, and
:> translating that into defining a class ChessClub that inherits Set.

: Why? It has a set of people, why would that be a problem?

The ChessClub should have an instance variable to hold the collection.
The Set (or whatever kind of collection you wish to use) of people is just
one attribute of ChessClub.

What if I have a subclass of ChessClub and I want to use some other kind
of collection other than Set (a Dictionary maybe, or some sort of
persistence managed store for example)? Do I add an instance variable to
my subclass of Set to hold this special kind of collection? Get's ugly.
If the instance of set is in an ivar, I can change it to whatever I like.
Also, maybe my ChessClub has no need for all the semantic baggage of Set
(more than 60 methods in the flavor of Smalltalk I use).

-Carl
------------------------------------------------------------------
Carl Gundel carlg@libertybasic.com Shoptalk Systems
author of Liberty BASIC, twice a PC Magazine Awards Finalist!
http://www.libertybasic.com
------------------------------------------------------------------

panu wrote:

>> The correct relationship is part-of. People are part-of a ChessClub in
>> the same way that an engine is part-of a car.
>
> Almost, in my opinion. Consider that 'people' is a set/plural
> but 'engine' is a singular element. Therefore I think we should
> say: "A set of people can be a *subset* of a ChessClub".

Actually, a chess club has a collection of people; The collection of people
is a part of the chess club. No different than an engine is part of a car.

> I gather what you're saying is that if there is a proper
> type-of relationship between two classes, /then/ it is ok
> (= safe) for the subtype to inherit implementation from
> its supertype. Right?

Code sharing and subtyping are orthogonal. You can have code sharing
relationships with no subtyping, and you can have subtyping relationships
with no code sharing.

In Smalltalk, it so happens that there is only one hierarchy, namely the
code sharing hierarchy, which forces us to conflate code sharing and
subtyping. On the surface this looks like a compromise, but in reality it
is quite elegant: Code sharing (good for the implementor) and
substitutability (good for the user) are expressed in exactly the same data
structure!

-anthony (a Wilfian dogmatist if ever there was one)

"Mark van Gulik" <ghoul@attglobal.net> wrote in message
news:2caa87f8.0308121317.63025522@posting.google.com...
> "Peter van Rooijen" <peter@vanrooijen.com> wrote in message
news:<3f38f235$0$49110$e4fe514c@news.xs4all.nl>...
> > "Guillermo Schwarz" <guillermo_schwarz@hotmail.com> wrote in message
> > news:3f38e49d@news.totallyobjects.com...
> [...]
> > > or a more real example: a Dog is a Cat that barks
> > > instead of meows, so meow() calls bark().
> >
> > I've never seen code with such classes, much less it being called a
"real
> > example". Now I am sure you are kidding.
>
> How about OrderedCollection>>at:? Or Dictionary>>add: (if you think
> that one's ok, you must instead have a complaint with
> Dictionary>>select.

Mark,

I don't know which dialect this is in, but I think I understand your point.
I had not induced that Guillermo had this in mind. If I'm right it is the
same thing that Nathanael Shaerli has researched for Squeak and to some
people it's amazing how many funny inheritance things (such as blocking) are
going on in its collection library.

However, I don't think this (what Nathanael researched for his traits study)
is a result (or an example) of implementation inheritance. Rather it is
mostly a result of not having multiple inheritance.

But tell me which dialect I should look in and I can tell you exactly
without having to speculate what you might mean.

> Smalltalk has plenty of other meows and barks.
> It gets by, but there are some truly ancient potholes that will never
> be filled.

Perhaps you know some really good examples of II in a Smalltalk library.
That would be good, to have some examples we can all agree are II and then
can use to discuss how "good" or "bad" it is.

Regards,

Peter van Rooijen
Amsterdam

Anthony Lander <anthony.lander@e-x-c-i-t-e.com> wrote in message news:<7_i_a.5092$VG.203290@news20.bellglobal.com>...
> panu wrote:
>
> >> The correct relationship is part-of. People are part-of a ChessClub in
> >> the same way that an engine is part-of a car.
> >
> > Almost, in my opinion. Consider that 'people' is a set/plural
> > but 'engine' is a singular element. Therefore I think we should
> > say: "A set of people can be a *subset* of a ChessClub".
>
> Actually, a chess club has a collection of people; The collection of people
> is a part of the chess club. No different than an engine is part of a car.

True. A chess club may also have a collection of chess boards,
obligations, schedules, etc. It would be absurd to pretend the
ChessClub "is-a" collection of chess boards. It would also be absurd
to pretend it both "is-a" collection of participants and "is-a"
collection of chess boards. While Eiffel (and probably *very* few
other languages) can support this, you basically have to rename every
feature of one of the parent classes, making it look exactly like
aggregation anyhow!

As another poster pointed out quite nicely, the "has-a" is a much
weaker coupling, allowing the collection type to be selected upon its
merits, rather than on the complexity of the protocol that must be
supported in order to subclass. For example, if you want to rank the
players you might have to rip out most of the code in order to inherit
from SortedCollection instead of Set, only to discover that you really
need to inherit from Tree or Heap or Tournament.

Another poster also mentioned substitutability. If the set of players
is immutable you only have to worry about covariance of the parameter
type (Player), not contravariance. However, even when it's supported
by a language it's not always clear how best to use this distinction
(immutability).

In Avail one could have an abstract Club that "has-a" set of players.
ChessClub could be a specialization that also specializes the set of
Players to be a set of ChessPlayers. In fact, in Avail this would
simply be an issue of naming the specialized type "ChessClub". Any
time you had a Club that only contained ChessPlayers, that Club would
automatically have the more specific type "ChessClub". Of course, if
you need to be able to add members to the club you'll have to
introduce a mutable "variable" somewhere, either outside the whole
structure (i.e., a variable that holds the Club's current state) or
between the club and the set of members (i.e., a variable in the Club
that holds the immutable set that represents the current membership).


> > I gather what you're saying is that if there is a proper
> > type-of relationship between two classes, /then/ it is ok
> > (= safe) for the subtype to inherit implementation from
> > its supertype. Right?
>
> Code sharing and subtyping are orthogonal. You can have code sharing
> relationships with no subtyping, and you can have subtyping relationships
> with no code sharing.
>
> In Smalltalk, it so happens that there is only one hierarchy, namely the
> code sharing hierarchy, which forces us to conflate code sharing and
> subtyping. On the surface this looks like a compromise, but in reality it
> is quite elegant: Code sharing (good for the implementor) and
> substitutability (good for the user) are expressed in exactly the same data
> structure!
>
> -anthony (a Wilfian dogmatist if ever there was one)

I agree that these can sit well in the same structure, but that
structure should not be a tree. It should be at least a dag, but more
plausibly a hypergraph, and maybe, just maybe, a hyperset. Note that
my mention above of repeated inheritance in Eiffel above was to show
that that feature of Eiffel would be irrelevant with respect to
attempting to (mis)represent two "has-a"'s as two "is-a"'s, not to
endorse or reject Eiffel's capabilities.

"Peter van Rooijen" <peter@vanrooijen.com> wrote in message news:<3f3a5326$0$49117$e4fe514c@news.xs4all.nl>...
> "Mark van Gulik" <ghoul@attglobal.net> wrote in message
> news:2caa87f8.0308121317.63025522@posting.google.com...
> > "Peter van Rooijen" <peter@vanrooijen.com> wrote in message
> news:<3f38f235$0$49110$e4fe514c@news.xs4all.nl>...
> > > "Guillermo Schwarz" <guillermo_schwarz@hotmail.com> wrote in message
> > > news:3f38e49d@news.totallyobjects.com...
> [...]
> > > > or a more real example: a Dog is a Cat that barks
> > > > instead of meows, so meow() calls bark().
> > >
> > > I've never seen code with such classes, much less it being called a
> "real
> > > example". Now I am sure you are kidding.
> >
> > How about OrderedCollection>>at:? Or Dictionary>>add: (if you think
> > that one's ok, you must instead have a complaint with
> > Dictionary>>select.
>
> Mark,
>
> I don't know which dialect this is in

VisualWorks 5i.2.

>, but I think I understand your point.
> I had not induced that Guillermo had this in mind. If I'm right it is the
> same thing that Nathanael Shaerli has researched for Squeak and to some
> people it's amazing how many funny inheritance things (such as blocking) are
> going on in its collection library.

I think I read a paper on this in the OOPSLA proceedings quite some
time ago. The collection hierarchy was analyzed for commonalities and
differences of protocol, modulo renaming. An idealized inheritance
DAG was built up from the core functionality of the classes.

> However, I don't think this (what Nathanael researched for his traits study)
> is a result (or an example) of implementation inheritance. Rather it is
> mostly a result of not having multiple inheritance.

I discovered long ago that strong typing and multiple inheritance were
a package deal. Either one is a disaster without the other. It's a
little less clear what happens when you have both. There might be a
similar all-or-nothing relationship with generics, reflection, type
inferencing, proof-carrying-code, etc.

> > Smalltalk has plenty of other meows and barks.
> > It gets by, but there are some truly ancient potholes that will never
> > be filled.
>
> Perhaps you know some really good examples of II in a Smalltalk library.
> That would be good, to have some examples we can all agree are II and then
> can use to discuss how "good" or "bad" it is.

Ok, OrderedCollection has these subclasses in VisualWorks 5i.2 (with
some parcels loaded):
-SortedCollection (probably a mistake)
-LinkedOrderedCollection (workable)
-FontDescriptionBundle (ChessClub)
-EncodedOrderedCollection (missing visitor pattern for literal
encoding)
-MessageHeaders (ChessClub)
-AHSPersistentOrderedCollection (should be generated code or
aspect)

Similar nonsense exists in the Dictionary hierarchy. A trivial
example is CEnvironment, which (1) is a Dictionary that has strings
for its keys and values [oooh, ahhh], (2) is effectively a singleton
with a #postCopy method for some unknown reason, and (3) is a place to
put class methods that are directly and indirectly related to OS
environment variables.