It is the same when new would call initialize. You still have to 
explain the hierarchy concept (this time for looking up the 
implementation of initialize in the superclasses), and you still have 
to explain class methods (you don't think that we will teach our 
students to only create classes using #new, do you :-) Look at the 
Smalltalk exercises from Stephane's website - from the beginning we 
explain them why it is important to have descent initialization 
methods, and how to do this. This discussion does not try to remove 
that!! Nor does it teaches kids lies (like you, I do not believe in 
that, and it frustrated me even as a kid).

Summary of the discussion and points of action: (well, according to me 
:-) )
----------------------------------------------------------------
The whole point is:
- that there is an obvious need for this, seen that there are around 80 
identical sibling methods in the system.
- that lots of these sibling methods are in end-user classes - we are 
not talking about more technical/complicated implementations - by that 
time you found out the way to bypass the system anyway. Especially in 
this case, where it is trivial to 'bypass'.
- that a lot of these are actually valid - it is not that all of them 
need a parametrized initialize.

Hence this proposal (as far as I understood).

Objections I have read are:
- will break existing books/culture/history
- enforces a bad programming practice (of not having appropriate 
initialize methods that take necessary arguments)
- might introduce problems for people confusing #initialize with #reset,


But at least one thing is very clear to me: an alternative is needed 
for the current situation. Since although we are all used to it, the 
existence of so many sibling methods means that something is very 
wrong. The refactoring solution for this problem is to 'pull up' the 
methods, and that is basically what the proposal does. It can still be 
circumvented, and I do not think it poses real problems. So, all those 
people out there: maybe you can propose some alternative? I can imagine 
tons of stuff (but will not spoil the fun for * a certain person* that 
I know is currently working on something and will want to do that 
himself :-) ).


On Monday, Sep 15, 2003, at 18:31 Europe/Zurich, Ian Piumarta wrote:

>  [ cut some Kent-stuff]

> 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? ;)
>
> (Once you've mastered that, try "browse protocol" for some real fun. ;)
>
> 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" ;).  Wouldn't the real 
> final
> solution be to simply point out the "inheritance" button (and similar) 
> to
> new Squeakers???  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. ;)

> (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. Squeak's 
> "inheritance"
> button shows your straight-off the Way Things Are. ;)
>
>> The alternative is to make sure that there is a method to represent
>> each valid way to create an instance. Does this result in a
>> proliferation of instance creation methods? Almost never. Most
>> classes only have a single way to create an instance. Almost all of
>> the exceptions only have a handful of variations.
>
> 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).
>
> 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).
>
> (FWIW, NeXT introduced this +alloc/-init pattern [which replaced a
> perfectly good, Smalltalk-like +new/-anything-you-like pattern] for one
> reason alone: to support messaging to remote objects.  I suspect the 
> only
> reason they had to do this was a lack of introspection metadata at
> runtime, on instances that can have mixed primitive/object types in 
> their
> state -- two problems from which Smalltalk definitely does not suffer.)
>
> I'll shut up now and let you get on with the fun and games.  ;)
>
> Regards,
> Ian
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org