until someone changed Association>>= to also compare values.

subclassing does not mean that technically it is wrong. subclassing is reuse so reuse is happening

but at the cost of bending APIs and killing the poor maintainers with yyy ^ super xxx and should not understand.

Stef

2013/7/21 St�phane Ducasse <stephane.ducasse@inria.fr>

On Jul 21, 2013, at 5:36 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2013/7/21 Igor Stasenko <siguctua@gmail.com>

Yes, but where are the guarantees that you don't?
Just think from outsider's point of view: when he sees

Announcer subclass: #Foo

what he will think first:
- aha, this guy implements own kind of announcer
or
- aha this guy reusing announcer
or
- aha, this guy doing both things at the same time (a worst possible
alternative)

and how many abuses like that, he should see before making a logical conclusion:
- aha.. this is the way how i should do as well.

Interesting how many people in this list think that "Announcer subclass: #TxEditor" provides special implementation of announcer named TxEditor?

Many
this is composition using inheritance and inheritance should not be used like that.

Announcer subclass: #GreedyAnnouncer

Announcer subclass: #RemoteAnnouncer

Are quite different from

Announcer subclass: #Customer

This is not because subclassing can be used that we should do it.

We suffer during years from
Dictionary subclass: #Set
and other beauties.

Because to me it is not practical design issues when we talk about subclassing Announcer.