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
If I remember correctly at least on array this was the normal behavior since we wanted to shortcut the initialize invocation cost. Now for Set I do not know.
Stef
On 4 avr. 06, at 20:47, John Pierce wrote:
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
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
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
It would be nice to get some benchmarks (running to bed now)....
Stef
On 4 avr. 06, at 22:28, nicolas cellier wrote:
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
nicolas
is the init: -> initialize calls works in your image. Just alwasy cautious with those stuff. Andreas was really surprise that squeak woudl continue to work and not dead slow when I introduce in my image super new initialize :) but we cannot be that lucky all the time
On 4 avr. 06, at 22:03, nicolas cellier wrote:
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
Le Mardi 04 Avril 2006 22:50, vous avez écrit :
nicolas
is the init: -> initialize calls works in your image. Just alwasy cautious with those stuff. Andreas was really surprise that squeak woudl continue to work and not dead slow when I introduce in my image super new initialize :) but we cannot be that lucky all the time
The change was not harmfull : so far i can browse compile open method finders etc...
But the #init: change is really simple, nothing comparable with putting initialize as a default in the whole image.
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
Le Mardi 04 Avril 2006 23:14, nicolas cellier a écrit :
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
By luck, the file out order does not break a fresh 3.9a7020 image...
But i'll be more carefull next time
Nicolas
squeak-dev@lists.squeakfoundation.org
-
John Pierce -
nicolas cellier -
stéphane ducasse