Yes to all, I always hated the #initialize in class side, I think we
should divide them. It will be easy to remove the #initialize in
Behavior and rename it to something else that is called during the real
initialization of the objects.
In the long time I think we should change the initialize name to
something like "doWhenTheClassIsInstaller" or maybe less verbose :P
I am not sure about lazy initialization, but it also is a nice solution.
Cheers,
Pablo
On 17/01/2024 21:37, stephane ducasse wrote:
Hi community
I would like to get use your ideas.
Here is the case
Context: Class side initialize are not good.
We fixed a bug with guille today (should do a PR) this bug was breaking
some projects by changing the superclass of classes to Object. Radical!
It was produced by the removal of DependentFields in Object and the
removal of the class side Object initialize method
Needed to initialize DependentFields (RIP).
Doing so when a class was doing a super initialize it executes the
Behavior>>#initialize (which reinitialize the class and its superclass) and was not
reachable before because blocked by Object class>>#initialize.
Two Situations.
When we do a class super initialize there are two cases
Case 1. the super reaches Behavior>>#initialize and your class gets
killed.
Solution 1. Easy we will define a class side initialize method to protect the
execution of Behavior>>#initialize.
Ideally raising a warning so that people can find their problems.
Case 2.
You have a little hierarchy Root and Subclass1 Subclass2 classes
Root class defines an initialize method.
You should not redefine initialize in Subclass1 and do a super
initialize
else we get a double initialize. Not easy to grasp so I guess
that many people are making this mistake.
Solution 2.
Cyril added a rule in a ReleaseTest (yes this is cool and we
should use more rules and not code by hand in the releaseTest)
that checks for no class side super initialize in Pharo.
Now long time ago I thought that this class initialize is not that good and
that I would like to have
a way that class state dependencies do not have to be resolved by the
developers by initializing first A then B
but that the system could do it automatically. In this case we would not need
initialize by class construction.
Do you have an idea how such design could be?
I’m too dead right now to think but to me it feels a bit similar to lazy
initialization.
If all the shared variables would be only accessed by lazy accessors then we do
not need to initialize them statically.
Now this is a bit extreme but this is to illustrate my wish.
So let us know :)
Stef
