Of course, Dictionary was somehow a Set, but somehow behaved more like a Bag (it could be seen as a Bag of values w.r.t. #do: behavior),. But we still solved it with inheritance, just with an intermediate HashedCollection capturing common abstract behavior... 2013/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr>
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.