On Mon, 15 Sep 2003, Ned Konz wrote:

(Ned -- this isn't directed at you [you'd have figured that out anyway ;].
I'm just dropping it into the ether to see if it reacts with anything
volatile... ;)

> On Monday 15 September 2003 02:20 am, Noury Bouraqadi wrote:
> > Sorry, but its part of the Smalltalk conventions to make new send
> > initialize (see the Kent Beck book about Smalltalk best practice
> > patterns).
>
> Where did Kent say that?

And when did Kent become the authority on what constitutes "The Smalltalk
Conventions"?

> I do see (under Constructor Method, p. 23):
>
> The most flexible way to represent instance creation is by a simple
> "new" method, followed by a series of messages from the client to the
> new instance.
> [ followed by a discussion of why that's hard to figure out when
> reading]

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