Though, Dictionary was technically a Set of Associations, until someone changed Association>>= to also compare values. 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.