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

This is not because we have a dynamically typed language that we should not use subtyping.
Have a look at my lecture there are slides on subtyping.

Compare:�

OrderedCollection subclass: #Poem

of course a poem is a collection of word. Now it is not a subtype of collection!!!

OrderedCollection subclass: #UniqueOrderedCollection

or compare

OrderedCollection subclass: #Stack

vs.

Stack subclass: #HanoiStack

Think in terms of API and polymorphic objects

I agree with your examples. And I never build my domain "container like classes" as subclass of OrderedCollection (or friends). But Announcer to me is different concern. It is like subclassing Object as Tudor said.

What is all api of Announcer?

Announcer allSelectors

It should be "Announcer selectors" (it is 16 methods). And I think it is wrong to name all methods of class as API.
And I think Announcer API can be reduced to just 5 methods: #announce:, #on:do, #subscribe:send:to:, #unsubscribe:and #week. All others are private or just convenient aliases (maybe already deprecated).
And this 5 methods is exactly what I need to subscribe on "event service" with enough flexibility.
So when I implement my domain "event source" I need superclass which will supply to my service such nice API. And now there is only Announcer class for this.

I were look at Announcer hierarchy. What do you think about SystemAnnouncer class? It has strange implementation. It is subclass of Announcer and it has another announcer instance named "private".