On Jul 21, 2013, at 7:30 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

Though, Dictionary was technically a Set of Associations,

yes but API(DICTIONARY) is not the same as API(SET) => ARGHHHHHHHHHHHHHHHHH

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.