>I sent an email but nobody reacted but I still want to raise the
>following issue: automatic initialization of instances.

I saw three messages.

>Why Behavior>>new does not call automatically Object>>initialize (or
>others specialized ones)?

*snip*

>I wrote the following stupid finder and found in the Squeak2.6 image 60
>occurences of new ^ super new initialize

Perhaps its because this "solution" isn't general enough.  Have you 
considered that 60 classes using the method you describe means that 
there are several hundred that do not -- or have inherited what they 
need already?

In particular, many classes REQUIRE parameters to know how to 
properly initialize instances.  Some (not enough) override new to 
alert unwary users from doing so.

I am not suggesting that the "convenience" of an automatic call to a 
default #initialize might not be useful, but it WOULD trade the time 
of additional message sends for EVERY INSTANCE CREATION IN THE 
SYSTEM, for mere "convenience."  In practice, after few weeks of 
coding (and a quick read of Ralph Johnson's "top ten bugs"), I never 
made the mistake of failing to write the initialization code, learned 
the idioms for those classes for which it is straightforward, and 
learned from the blue book how to handle the cases for which it is 
not.  Any savings in text and code is TRIVIAL compared to the costs 
of requiring every class to go through your empty initialization 
message send, particularly if the standard initialization (all nil) 
is satisfactory.

The pedagogical advantage claimed is also something of a canard. 
Users will still need to understand metaclasses in order to deal with 
objects for which the #initialize protocol is insufficient.  In 
short, Smalltalk is not CLOS, and I'm not sure that losing the 
ability to define arbitrary metaclass protocols is worthwhile.  I for 
one am not particularly willing to have to add to the instance side 
of every such object a foundry-like protocol.

>Then I have the following suggestions
>	- why basicNew is not called allocate because this is what is does?
>
>	- then new could be really
>		new (initialize(allocate))

And here's the really neat thing about Smalltalk.  You can have it 
your way!  What's more, if it is useful, natural selection will lead 
to its adoption.  My suggestion, however, is that it would be far 
more intelligent until your view is adopted that you adopt the new 
terminology and implement it so things can live side by side, rather 
than trying to supplant it with an experiment.

In particular, why not adopt

	create

as your instance generator with automatic 0-adic initialization, and

	allocate

as your instance allocator without initialization (identical to basicNew)?

This, we can have our new, basicNew, and metaclass confusion; while 
your world does what you want.  If the world is ready, and if your 
paradigm is better, it will in time be adopted.  If not, we all still 
will have learned something.

BTW, I agree that allocate is better than "basicNew" in describing 
what occurs in practice.  However, it does not carry with it the 
convention of being non-overridable.