Here's a class initialization scheme that worked well with in the past:

   1) The classes of a package are loaded in any sequence (but not 
initialized!)
   2) Class initialization is done by a kernel method that initializes 
ALL classes as follows:
     2a) First, send #initialize to ALL classes that have it implemented.
     someClass class>>initialize initializes constants etc. It is local 
to the class, only using kernel classes such as String, Integer, ...
     2b) Second, send e.g., #squeakInitialize to ALL classes that have 
it implemented. someClass class>>squeakInitialize sets up required 
links. It can reference any class, since all classes have been loaded.
     2c) If #squeakInitialize can only be run in a certain sequence, the 
classes are too fragile and should be redesigned.
   3) Some library classes did not tolerate repeated initializations. We 
regarded that as a weakness and fixed the offending classes to enable 
the above scheme.

Cheers
--Trygve

On 25.11.2006 06:32, Ralph Johnson wrote:
> On 11/24/06, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
>> I put forward some work I am doing as a kind of example scenario, how
>> would the process handle this one, kind of thing.
> 
>> I am looking at pulling together some recent tweaks and bug fixes to the
>> DateAndTime code. (see mantis 474 which doesnt have my final code as yet
>> , see below).
> 
>> Atomic loading might help, since loading in code that modifies
>> DateAndTime-#now, really upsets the code that is loading and time
>> stamping the newly installed methods as they are compiled. As soon as
>> someone calls #now, before the class is fully loaded and importantly
>> before the class has been initialized we crash and burn.
> 
> i don't know the answer to this, but I will guess.
> 
> I am far from a Monticello expert, but I have been looking at the code.
> It looks to me that class PackageLoader could be changed to load 
> atomically.
> Basically, instead of making one pass through MCDefinitions (such as
> MCMethodDefinition, MCCLassDefinition and MCScript) and loading each
> one, the PackageLoader should first make a pass doing a preload and then
> a pass doing a load.  Classes will be loaded during the preload and
> methods will be compiled during the preload, but actually installed during
> the load.This would mean that you wouldn't run the compiler during the
> actualy loading of methods.  Something similar would have to be done
> for unloading.
> 
> Do people who know more about MC than I do think this  would work?
> 
>> Second Problem, I am struggling to work out how to test my new code 
>> fully.
> 
> No code is every tested fully.  The question is whether it is tested 
> enough.
> Perhaps you should settle for less complete tests.
> 
>> 1. It turns out that the millisecondClockValue supplied by the vm, is
>> one of those SmallInteger things which will roll over every once in a
>> while. One needs to set up the scenario just before and after the roll
>> over in order to see that everything is handled smoothly.
> 
> Mock up the millisecondClockValue from the VM.  Make a little "clock"
> object that you can replace with a mock object for testing.
> 
>> 2. I have organised this implementation around a call
>> #milliSecondsSinceMidnight, and it is necessary to test that the
>> transition from 23:59.59 to 00:00.00 also goes smoothly.
>>
>> So within my test environment I have no control over the vm's
>> millisecondClock. Secondly all of the interesting things, like timing
>> offsets are stored in Class variables so my test code can't really mess
>> with them. The best I can probably manage is to test the 'algorithm' and
>> hope for the best. Any ideas?
> 
> Mock these as well.  Redesign the class so it is easy to test.
> 
> Or just have easier tests.
> 
> -Ralph
> 
> 


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway