Andrew-

Thanks for the comments.

"Andrew C. Greenberg" wrote:
> One example I can think of offhand is the proposed implementation of the
> Singleton pattern in Wolf, et al.'s excellent Design Patterns in
> Smalltalk.  The archetypal example replaces the existing new method with
> a method indicating an error case, and adding a method, say "singleton"
> which will either answer the cached singleton; or on the first such
> call, create, cache and answer the newly cached singleton.

Pulling out "The Design Patterns Smalltalk Companion" by Alpert, Brown
Wolf, page 94 and paraphrasing the code:

Singular class>>new
  self error: 'Singular cannot create new instances'

Singular class>>current
  UniqueInstance isNil
    ifTrue: [UniqueInstance := self basicNew].
  ^UniqueInstance
  
So, the idea dodges another bullet in practice. However, in theory
"Singular class>>current" could have just as well called "super new"
instead of a "self basicNew" if there was complex initialization in the
superclass, which would make the point. 

It's a bit of a lame kludge, but this may produce the right behavior in
the complex case at a cost of a bit of lost clarity:

Singular class>>new
  UniqueInstance isNil
    ifTrue: [UniqueInstance := super new].
  ^UniqueInstance

Singular class>>current
  ^self new

The loss of clarity is that one can now call "Singular new" and not get
a warning -- just the Singleton instance.

It seems like "new" may be a method fraught with "super" issues -- since
both examples so far reference it. Do people think most of the
legitimate uses of the general "super" revolve around that? Could this
be dealt with by refactoring class side instance creation with some sort
of extra layer of calls for initialization?

> Design Patterns in Smalltalk contains other examples as well.

I'll have to revisit the book some more.

> I agree with Paul that in many, perhaps most, cases, cross-supering will
> lead to various horrors, some of which will not rear their head until
> substantial reuse is made. Some of these are galling to debug.  

Misery loves company. :-)

> But the fact that the construct can be abused 
> doesn't mean that the structure is necessarily corrupt.

I agree "super" is a nice and useful construct as it is. I'm just trying
to see if it can be restricted without too many ill effects in the
interest of producing alternate implementations of Squeak that may be
more efficient or flexible for some jobs. 

This is somewhat like for example how the more restricted blocks in
PocketSmalltalk make new things possible (running Smalltalk on the
PalmPilot) although obviously the more general blocks are more useful.

-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