On Nov 27, 2006, at 3:27 AM, Ralph Johnson wrote:



>> "SystemEditor is a mechanism for atomically loading a set of changes
>> to the system. It's intended to be used by tools such as that move
>> classes (or parts of classes) between images, such as Monticello,
>> Monticello2, change sets, fileIns etc.
>>
>> It provides a familiar interface for making changes, but does not
>> execute the changes until it receives a #commit message. This  
>> makes it
>> easier to update existing tools to load their changes atomically."
>>
>>
>
> I am not sure how it is supposed to be used.  I couldn't find any
> tests that actually tie it in to anything.
>
> Are ClassEditor and MetaclassEditor supposed to replace Class and
> Metaclass? It looks ot me like I would have to change the
> MCPackageLoader to use ClassEditor and MetaclassEditor whenever it
> currently uses Class and Metaclass.  Is that the idea?
>
>

Yes, ClassEditor and MetaclassEditor are meant to be standins for  
real classes and metaclasses. However, the idea is to create a  
SystemEditor to use in place of a SystemDictionary. So you'd do  
something like "aSystemEditor at: #String" to fetch a ClassEditor on  
String.

On the other hand, SystemEditor is fairly ambitious in that it aims  
for truly atomic loading - all changes are installed using a single  
primitive call, so the only possibility for an incomplete load is  
misbehavior of the primitive. This code has lots of unit tests, but  
hasn't had much real world usage. I agree that your earlier approach  
of splitting loading into two passes gives a better balance of risk- 
of-incomplete-loads vs risk-of-bugs-in-the-loading-code, at least for  
the short term. At some future point, we can look at either modifying  
MC1 to use SystemEditor, or moving to MC2.

I do intend to keep moving forward with both MC2 and SystemEditor,  
though progress is slow because I don't have much free time. It may  
or may not be useful in time to incorporate into the 3.10 process,  
but either way, I think your focus on process rather than technology  
is what's needed to keep Squeak vital.

Colin