About MC for managing the image

[stéphane ducasse]

Hi colin

I just discussed this point with avi. My take on that is a bit  
extreme (and does not fit a system like squeak)
but I would say that per design you should not have initialization  
order.


>> Both of these cases are solved by simply asking MC to load or  
>> merge the two packages together, rather than asking it to load  
>> them sequentially.  The load strategy it uses is very simple: a  
>> superclass always needs to be loaded before its subclasses, and a  
>> class always needs to be loaded before its methods.  Additions are  
>> always done before removals, and removals are done with the  
>> inverse rules (first remove methods, then classes, then  
>> superclasses).
>>
>> What you don't get to do in that case is specify anything about  
>> the load order yourself.  I think the cases where specifying this  
>> is necessary are going to be very rare, but certainly they will  
>> happen.  That's what the update stream is useful for: simply put  
>> two configurations in (one of them, maybe, with only a single  
>> package) to ensure that loads happen in the correct sequence.   
>> This should only be needed for delicate migrations, I don't think  
>> it should ever be needed for every time a group of packages is  
>> loaded together.
>>
>
> One thing that isn't addressed here is initialization order. If  
> package A depends on package B, A should be completely initialized  
> before initialization of B begins. I don't think we do this  
> correctly at the moment.
>
> Otherwise, I completely agree. We should use sequences of  
> Configurations in the update stream for those special cases where  
> we need specific intermediate states. In all other cases, MC's  
> internal load ordering should be fine.
>
> Colin
>