Hi Ian,

> Okay kids, enough fun and games concerning initialisation.  
> Now it's time to go back and revise "Squeak 101"...
> 
> Open a browser on some class with simple (but not trivial) 
> initialisation behaviour, say "EventSensor".  Then on the
> class side select "new" in the method pane.  Then click the
> button labeled "inheritance".  Still with me? Now switch to
> the instance side, select "initialize" in the method pane,
> and hit "inheritance" again.  Does it get any easier? ;)

Certainly not, but what's your point exactly? To extend your example a
little, go to some class where you don't know if it has any initialization
(say: PluggableButtonMorph) and look at it. We see a method called
#initialize here - do we know if that is called by #new? Let's try to find
out - we click on the class and look for #new. Well, no #new here so we
don't know. Now what shall we do? Should we open a protocol browser and
navigate through the hundreds of (meta-level) methods until we find #new? Or
should we climb the class hierarchy through AlignmentMorph, RectangleMorph,
BorderedMorph up to Morph until we find it?

> Inventing arbitrary conventions seems to me (trying to remain 
> humble, but finding it increasingly difficult) a way to make
> the learning curve steeper, not shallower -- and to obfuscate
> the (very many) cases in which specific initialisation behaviour
> is used (I spent two minutes looking for any class that used
> "^super new initialize" ;).

"Arbitrary" sounds like a harsh word in this context. Let's rather try to
get some real data. Here is a little (somewhat dangerous) doIt which tells
you about it:

Object compile: 'fooInitialize self error: ''Yes initialize is called'''.
initializer := Object compiledMethodAt: #fooInitialize.
count := used := 0.
Smalltalk allClasses do:[:cls|
	count := count + 1.
	(cls == CompiledMethod) ifFalse:[
		fooClass := cls subclass: ('Foo', cls name) asSymbol
instanceVariableNames: ''
		classVariableNames: '' poolDictionaries: '' category: 'Foo'.
		fooClass addSelector: #initialize withMethod: initializer.
		[fooClass new] on: Error do:[:ex| 
			ex messageText = 'Yes initialize is called'
ifTrue:[used := used + 1].
			ex return].
		fooClass removeFromSystem.
	].
].
Object removeSelector: #fooInitialize.

In a full 3.6 system this yields:
count: 1756
used:   740

which means roughly 42% of all of the classes already use this pattern.

> Wouldn't the real final solution be to simply point out
> the "inheritance" button (and similar) to new Squeakers???

See above. I wonder how this would even address the problem. You simply
don't know when you look at a class if some superclass already implements
the method. I'm just trying to imagine this: Okay, we first implement a
method #new which simply calls "super new" so that afterwards we can press
the inheritance button to see if the superclass already implemented it. Then
we see that the superclass does and we delete this method again. A "real
final" solution? Not to me, no.

> The IDE is there for a reason -- get used to leveraging
> development, and understanding of the hierarchy, off it! 
> That quicker you master that, the quicker you master all
> of Squeak. ;)

So true. However, consider the learning curve. Do you _really_ want to
expose people to the meta-level of Smalltalk at the very beginning? I say no
- and the new/initialize pattern introduces a convenient way to defer that
exposure for a while. I find it disturbing that there is apparently a wide
"fear" that having the new/initialize would "prevent" you from using other
methods of initialization. There is no such issue - you are free to choose
any initialization which you want, just that it is considered an "expert"
rather than a "newbie" feature. Similiar to implementing #parserClass -
there _is_ a good reason why the browser complains about implementing such
methods.

> (This reminds me of a sad [but maybe unavoidable] situation we have in
> science education -- especially for biology, chemistry and 
> physics. You go to school and they tell you a nice, simple story. 
> All smiles.  Then you go to high school and spend 6 months
> unlearning that story so that you can replace it with something
> more complicated. Then you go to university and spend a year
> unlearning the second story so you can replace it with
> something that finally begins to approach what's presently 
> considered to be the most accurate model of the Way Things Are.

There are many things to be said towards that but in its shortest version
the consistency of the story is not the problem - the problem occurs when
you are being lied to in school and intern completely false stories without
even being told that "yes, there is more to it, and you will learn it later
or can read it up here". E.g., for most people who later go on to advanced
education (and that still isn't the majority of kids) it is more important
to know that you are in fact looking at a simplified theory, perhaps even
being pointed at its inconsistencies.

> Squeak's "inheritance" button shows your straight-off the Way
> Things Are. ;)

So I guess you'd go straight for Einsteins theory of relativity and have the
kids derive Newton's "laws" by themselves? Good luck - I'd like to see how
many kids would get that. 

Similarly, the meta-level of Smalltalk _is_ such an "extended" theory of how
the world works. Just look at how many people abuse this facility daily for
stupid utility methods or entire sets of stuff that have no right for
existence in the meta-class layer (Utilities anyone?).

> Well, curiously enough, having spent some time programming 
> using the ObjC Foundation and Portable ObjC's "objpak", I find
> myself deliberately breaking the Foundation +alloc/-init pattern
> for many of my non-trivial classes (thereby completely ignoring
> the "golden rules" and living somewhat dangerously) and implementing
> it explicitly for all my trivial classes in objpak (which uses
> a nice, simple +new for allocation with no
> formal initialisation protocol whatsoever -- like in Smalltalk).

Sure. But you _are_ an expert. You also understand Einstein (I hope ;) Many
of the people we may want to teach Smalltalk to are no experts, and will
never become one.

[Completely OT meta note here: I always had the feeling that most
Smalltalkers love the way the entry barrier to the system is set. It ensures
that only people "above threshold" will get into it. It's this kind of
self-selection that _really_ drives me crazy when I think about wide
adoption. It's the ivory tower syndrome all over]

> Minor metapoint: the former (breaking the rules) is _way_ scarier (but
> often the only rational solution) than the latter (inventing 
> new rules to suit each class as I go along).

Yes. And that's one of the things that an _expert_ learns. When to break the
rules and what the implications of it are. It is a Good Thing that breaking
the rules is scary - it ensures that there is a tangible fence to the expert
features rather than occasionally using something completely wrong without
being aware of the consequences. [Incidentally, this is one of the (few)
real advantages of using facilities like mirrors instead of just messages on
the object - it ensures you know what you are doing and you proove it by
referring to the mirror instead of just sending some random message to an
object].

> I'll shut up now and let you get on with the fun and games.  ;)

No need to shut up. The only thing I'd like to acknowledge is that you are
an extremely rare species - not only a Smalltalk but also a VM and
meta-level guru. That gives you a unique point of view on many of these
issues (and is to a large part the reason why I'm not simply ignoring the
post ;) but keep in mind that the pattern we're discussing here is intended
to simplify the life for newbies rather than experts.

Cheers,
  - Andreas