Jon-

Thanks for the example and feedback. 

Jon Hylands wrote:
> (off the top of my head)
> 
> OrderedCollection subclass: #SomeSpecializedOrderedCollection
> 
> SomeSpecializedOrderedCollection class methodsFor: 'instance creation'
> 
> new: size
>         self error: 'It is not appropriate to send #new: to this class, use
> #new instead'.
> 
> new
>         ^(super new: 100) doSomeSpecializedInitialization

This definitely is a good example of where this unrestricted super
behavior is useful.

However, if I understand the example correctly, one could (admittedly
"counter-contrivingly") re-implement this with the kludgy:
  
new: size
    (size ~= 100) 
      ifTrue: [self error: 'The initialized size must be 100']. 
    ^(super new: 100) doSomeSpecializedInitialization
 
new
    ^self new: 100.

I'm not saying this is pretty, or that it might not produce occasionally
unexpected run-time behavior (i.e. the class is almost always passed 100
as the argument to new: but sometimes it isn't). The question is, is
this kludge a good enough solution given other possible benefits that
might result from restricting "super" inheritance behavior?

> If you're building a class hierarchy from scratch, or if you are free to
> modify the superclass behavior, then it is easy to not do this. 

With Squeak we can refactor the base system, so I don't consider that a
show-stopper for this approach as far as the base classes (assumign it
isn't endless work). 

To quantify this, anyone have a snippet of code to search on calls to
the super pseudo-variable which are not the same as the method the call
is in? This doesn't seem like something easy to do from the browser. 

> But
> especially in a case like this, involving a heavily used base system class,
> I would much rather do this than have to come up with some convtrived way
> of dealing with restricting the inherited behavior.

Is that then when unrestricted super behavior is most used -- when the
subclass is written or maintained by someone other than those who wrote
the superclass? 

The issue is then, how often would this occur in practice dealing with
building on top of someone else's application code? 

I'm trying to get at the cost/benefit of this alternate approach.
Clearly your example points out a cost, the question is, is it high?
So, one question is, is this example common? Are contrived workarounds
good enough if the other benefits are significant? How often do people
have to do something like this? 

Are there any more good examples out there of where "super" calls for
non-identically-named methods methods makes sense?

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com