Semantics of Set>>new in Squeak 3.9 -- To initialize or not to initialize?

> Hi all,
>
> I am looking at the "new" class method in Squeak 3.9 (and maybe prior
> to that). It appears that most classes implement "new" as:
>
>   ^ self basicNew initialize
>
> which is implemented in Behavior. But the "Set" class re-implements
> "new" and does not invoke initialize.
>
> Is this behavior intended? I had a few classes that derive from
> Dictionary and used to work without calling initialize. Now I must
> explicitly invoke the constructor.
>
> Is this lack of congruency the desired behavior?
>
> John
>
> --
> It's easy to have a complicated idea. It's very very hard to have a
> simple idea. -- Carver Mead
>
>

> Hi all,
>
> I am looking at the "new" class method in Squeak 3.9 (and maybe prior
> to that). It appears that most classes implement "new" as:
>
>   ^ self basicNew initialize
>
> which is implemented in Behavior. But the "Set" class re-implements
> "new" and does not invoke initialize.
>
> Is this behavior intended? I had a few classes that derive from
> Dictionary and used to work without calling initialize. Now I must
> explicitly invoke the constructor.
>
> Is this lack of congruency the desired behavior?
>
> John
>

> Le Mardi 04 Avril 2006 20:47, John Pierce a écrit :
> > Hi all,
> >
> > etc...
>
> Well, a lot of indexable-like classes do implement #initialize: , and a few
> implement #init: (Set and some subclasses of it, and also SharedQueue).
>
> Sure, it would be more uniform and highly desirable to rename #init: into
> #initialize: , but that said, we can say that the initialization function
> does exist in Set (and thus Dictionary).
>
> etc...
>
> We just should rename this init: method...
>
> Nicolas

>
> OK, i put the proposed init: change in http://bugs.impara.de/ 
> view.php?id=3426
>
> BTW, Stef is right, Array (and eventual subclasses) won't call  
> initialize (for
> speed as stated in comment).
>
> If we want to factor implementation of new: , we can simply test  
> for the
> behavior being indexable or not and send one of the two initialize  
> path:
>
> Behavior>>new: n
>     ^self isVariable
>         ifTrue: [(self basicNew: n) initialize]
>         ifFalse: [self basicNew initialize: n]
>
> This would help deleting almost any other implementation of new:  
> but would
> cost one test at each creation. I let this responsibility to gurus.
>
> Nicolas
>
> Le Mardi 04 Avril 2006 22:03, nicolas cellier a écrit :
>> Le Mardi 04 Avril 2006 20:47, John Pierce a écrit :
>>> Hi all,
>>>
>>> etc...
>>
>> Well, a lot of indexable-like classes do implement #initialize: ,  
>> and a few
>> implement #init: (Set and some subclasses of it, and also  
>> SharedQueue).
>>
>> Sure, it would be more uniform and highly desirable to rename  
>> #init: into
>> #initialize: , but that said, we can say that the initialization  
>> function
>> does exist in Set (and thus Dictionary).
>>
>> etc...
>>
>> We just should rename this init: method...
>>
>> Nicolas
>
>
>

> Le Mardi 04 Avril 2006 20:47, John Pierce a écrit :
>> Hi all,
>>
>> I am looking at the "new" class method in Squeak 3.9 (and maybe prior
>> to that). It appears that most classes implement "new" as:
>>
>>   ^ self basicNew initialize
>>
>> which is implemented in Behavior. But the "Set" class re-implements
>> "new" and does not invoke initialize.
>>
>> Is this behavior intended? I had a few classes that derive from
>> Dictionary and used to work without calling initialize. Now I must
>> explicitly invoke the constructor.
>>
>> Is this lack of congruency the desired behavior?
>>
>> John
>>
>
> Well, a lot of indexable-like classes do implement #initialize: ,  
> and a few
> implement #init: (Set and some subclasses of it, and also  
> SharedQueue).
>
> Sure, it would be more uniform and highly desirable to rename  
> #init: into
> #initialize: , but that said, we can say that the initialization  
> function
> does exist in Set (and thus Dictionary).
>
> So there are two possible implementations of new:
> The one in Behavior for classes really declared as variableSubclass
>  (self basicNew: n) initialize
> The one in other classes, faking an indexable behaviour, but  
> implementing this
> behaviour indirectly by the mean of an indexable instance variable
>  (self basicNew) initialize: n
>
> Note that since #initialize: has no default implementation in  
> ProtoObject, it
> rarely super initialize:, but if you subclass, you'd rather call  
> super.
>
> Depending on where you are subclassing, you might have to define  
> either
> initialize or initialize: in your subclass, and i think that it is  
> tolerable.
>
> We just should rename this init: method...
>
> Nicolas
>
>
>
>
>

>
> However, i did not check that the change set has been filedOut with the
> correct order, and i should have tested in a new image before publishing...
> Ah, looking at the cs, it does not seem to be in the right order, sorry...
> I will publish a corrected cs.
>
> Maybe the file out could be sorted by method modification time (it would
> solve at least simple cases).
>
> Nicolas