On 17 January 2013 17:45, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
>
>
> On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko <siguctua@gmail.com> wrote:
>>
>> After some thought i decided to contribute my 2cents.
>>
>> First, i think it is impossible to introduce a (re)initialization
>> logic which would suit all different scenarios.
>> Because it is really depends on what is stored in class variables and/or
>> pools
>> and if you add subclasses and then instances into the soup, you might
>> end up with something
>> which is really hard to safely reinitialize, because it may have some
>> inconsistent state at different stages
>> of initialization. It also, sometimes an order of initialization is
>> important.
>
>
> Yes, but on *can* write idempotent class initialization code. �So that if
> the system does reinitialize on every load old code may break until its
> fixed, but new code will have the advantage of always being correctly
> initialized. �Note that in the VMMaker class reinitializations of the core
> VM classes (the interpreter, garbage collector, jit, etc) are done *on each
> launch of the simulator*, and *each vm generation*, let alone on each
> package load :). �[ I'm not recommending this :) ].
>
> One thing I do is when creating singletons for sentinels etc I check whether
> they've been initialized. e.g.
>
> initialize
> � � Sentinel ifNil: [Sentinel := Object new]

Knowing full well that I know next to nothing about concurrency in the
image, and so realising that this might be a complete non-issue: lazy
initialization and concurrency do not mix well.

But I do agree with your sentiment: idempotency is highly desirable,
and somehow forcing non-idempotent class initialisation to fail
quickly and noisily sounds like a good plan.

frank