On 26-Nov-08, at 2:53 PM, Andreas Raab andreas.raab@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