On Jul 21, 2013, at 7:30 PM, Nicolas Cellier <[email protected]> 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 <[email protected]> > > On Jul 21, 2013, at 5:36 PM, Denis Kudriashov <[email protected]> wrote: > >> 2013/7/21 Igor Stasenko <[email protected]> >> 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. >> > >
