>> I am also curious why you think that. Making subclasses is pretty much the essence of programming.
>
> I'm curious why you would feel the need to subclass OrderedCollection, have to agree with Levente.
>
> It's bad practice to subclass for no good reason, because you're much more likely to depend on the implementation details of your superclass, and not just its external interface. One shortcoming of Smalltalk in particular is that all the implementation details are visible, so they tend to get made use of. Which is perfectly fine for a personal computing system in one image, but not for a collaboratively maintained one, where we have to worry about breaking subclasses that are not in the image.
>
> So feel free to subclass away, but be prepared for dealing with the consequences later. Strong coupling is bad, and subclassing creates a pretty strong bound.

Ah, ok, now I got it.  This is what we're taught when we're new and
learning Smalltalk, and what we definitely want to tell newbies so
they don't go off and do something like that when they don't need to.

But we wouldn't say that about the current subclasses of
OrderedCollection such as WeakOrderedCollection or...  It's definitely
*rare* for that to be the right thing but not totally absolute.