Le lun. 4 mars 2019 à 21:35, Eliot Miranda <eliot.mira...@gmail.com> a
écrit :
>
>
> On Mon, Mar 4, 2019 at 8:26 AM Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
>> (1) the basic concepts are clear (and have been for a long time):
>>
>> - when a class initialize method is loaded, it is executed afterwards, if
>> and only if the source code changed
>>
>> - there are startUp[:] and shutDown[:] and SessionManager to handle
>> images coming up, saving and going down
>>
>> With these tools you can build any behaviour you want.
>>
>> I am not sure we need something else, except maybe more education
>>
>>
>> (2) the problem is much larger than just the class initialize method,
>> since that can call other methods (like #initializeConstants, etc, ..) -
>> even if the class initialize method did not change, a method further down
>> might have and could require re-initialization.
>>
>> For this reason I sometimes put a timestamp in a comment of the class
>> initialize method to force re-initialization since I known that I added a
>> new constant somewhere (much) further down.
>>
>>
>> Complex new features might do more harm than good
>>
>
> +1000. KISS.
>
Except that things are not simple if you have nested dependencies:
You have no way to control initialization order!
If (A initialize) will instantiate a B new that require (B initialize) then
you are screwed.
You then have to create several packages and load them in the right order
to work around the initialization.
This is one reason for resorting to lazy initalization: disantangle such
initialization dependencies.
But hardcoding every lazy initialization does not sound right.
A class>>accessMyClassVar
^MyClassVar ifNil: [self initializeMyClassVar]
Having a way to link the method #initializeMyClassVar to MyClassVar with a
declarative form by way of #<initialize> annotation is more universal/nice.
A class>>initializeMyClassVars
#<initialize>
MyClassVar := 1.
MyOtherClassVar := B new: 10.
Having an UnitializedStatic instance automatically becomeForward: whatever
initialized object is simple and legitimate magic.
I agree that maintaining the registry that links initializer to this
variable is the complex part
The easy part is when adding a new initializer method (this is the case of
installing a package in image).
The harder part is when changing or removing a previous initializer
(exactly like what happened to you recently with FFI).
>
>>
>> > On 4 Mar 2019, at 17:13, Ben Coman <b...@openinworld.com> wrote:
>> >
>> >
>> >
>> > On Mon, 4 Mar 2019 at 20:08, Norbert Hartl <norb...@hartl.name> wrote:
>> >
>> >
>> > > Am 04.03.2019 um 03:46 schrieb Ben Coman <b...@openinworld.com>:
>> > >
>> > > In relation to developing sample solutions for an Exercism exercise,
>> the following observation was made about class initialization...
>> > >
>> > > > class is initialized on load - and not when you modify it - so this
>> can be very confusing for users
>> > >
>> > > My first thought was to wonder if Quality Assistant could track
>> whether a class initialize method had been run after it was modified,
>> > > and display alerts.
>> > >
>> > > Alternatively, I wonder if a reasonable pattern would be to couple
>> class-side lazy initialization
>> > > with a pragma to reset a variable when the method is saved...
>> > >
>> > > MyClass class >> referenceData
>> > > <onSaveResetVariable: ReferenceData>
>> > > ^ ReferenceData := ReferenceData ifNil: [ 'reference data' ]
>> > >
>> >
>> > Isn’t the usual way to do that to register the class in the shutdown
>> list and implement #shutdown: ?
>> >
>> > To me a good minute to work out why I didn't understand you.
>> > Sorry, I meant <onMethodSaveResetVariable: ReferenceData>
>> >
>> > So when 'reference data' is updated and the modified method is saved,
>> > the variable gets lazy initialized *again* with the new definition.
>> >
>> > hope that is more clear,
>> > cheers -ben
>>
>>
>>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
