Stephane Ducasse wrote:

> I sent an email but nobody reacted but I still want to raise the
> following issue: automatic initialization of instances.
> 
> Why Behavior>>new does not call automatically Object>>initialize (or
> others specialized ones)?

I've wondered about this too. I've had a feeling that there is some good
reason from the PARC days or so, but which now is forgotten wisdom to
everyone but the original Jedis.

Andrew C. Greenberg wrote:

> 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.

This is what overrides are for, and are meant for, right? :-)

> 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.

....
> for mere "convenience."

Well, you know, *all* of Smalltalk is mere convenience. After all, all we
get is still universal Turing machines, there's nothing a high-level
language can do that the lowest-level implementation can't. Smalltalk is all
about convenience, or as I'd rather say, about suiting the human way of
thinking better. There are no purely technical advantages with high-level
constructs etc., in my view.

Also, it is an often iterated tenet of The Smalltalk Way never to trade
"convenience" (understandability and simplicity) just for some speed gains.
Having redundant code in 60 places seems to be an in-your-face violation of
this. Not to mention the top ten bug lists and book sections and lectures
and debugging hours that have been spent as compensation.

So I've assumed that there has to be a good reason.

> 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, 

This was the first reasonable motivation I've heard of. I made a few checks.

"Object new", traditional version (no initialize):

1.7 microsec

the same with "Object class>>new ^self basicNew initialize", empty
Object>>initialize":

2.3 us

new for a subclass of Object (to check time for looking up inherited
initialize, etc.):

no measurable difference (2.3 us)

So for one million new objects (my test case) you lose 0.6 seconds. Perhaps
this was a greater concern on a ~5mhz Alto?


But like I said I think there's got to be a design rationale for something
as obvious as this.

all the best,
Henrik