On 26-Nov-08, at 2:53 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Hi Colin -
>
> I was looking over SystemEditor and one thing that really surprised  
> me was the use of ClassEditors as proxies. What is the reasoning  
> behind it? It makes the design difficult to understand and extremely  
> hard to debug - I gave up trying to find out what causes the issue  
> with class migration when I effectively couldn't debug the editors  
> since all they would show me were those pretend-classes. Is there  
> some sort of debug mode to turn off all that evil magic? ;-)

The purpose of SystemEditor is to provide a way to atomically apply  
changes to the system, using an interface identical to the reflective  
interface already in use. The proxies provide protocol compatibility,  
while recording the changes, that need to be made. Then, when it's  
time to commit, it does all the class building, compiling, instance  
migration and so on, and finally installs it atomically with a mass  
become.

So the design is aimed at providing easy-to-adopt atomic updates. The  
increase in performance is icing, but it makes sense, I guess. Making  
a change involves a certain amount of overhead, and making the changes  
one by one incurs that overhead for each change. SystemEditor  
aggregates changes and can amortize the overhead across several  
changes. Monticello 2 benefits from this even more than Monticello1,  
because it deals with instance variables individually, and so incurs  
migration overhead for each ivar, rather than for each class.

I hear you though. If you think ClassEditor is evil, look at  
MetaclassEditor. ;-)

Colin