Stephen Pair wrote:

> I think DeltaClass should be reworked a little bit in terms of where it
> exists in the class hierarchy.  Here are a couple of observations about
> DeltaClass:
> 
> - it is used to record changes to a class (hence the name)
> - it is a subclass of Class
> - it serves as a delta for both classes and metaclasses
> - it (AFAICT) does not act as a Behavior

> 
> But, this is just based on a cursory examination of DeltaClass.  Is
> there significant behavior needed from its superclasses that would make
> this change problematic?
> 
> - Stephen

Your analysis is correct. However the reason I did this is based on my
previous experience of rolling your own Class-like things.

Firstly, if you "fork" the implementation of base and meta, you will have to
duplicate a lot of code and then keep the two synchronized. This is why I
have made DeltaClass act for both.

Secondly, the changes going into Behavior and friends are so frequent in
Squeak that if you "fork" here by creating a new DeltaDescription subtree
you will again have a different code base that you will have to keep in
synchrony with the galloping codebase of the usual implementations of
Behavior and friends.

If you look closer at these classes, there is a *lot* of stuff that has been
poked in there over time. Even if the deltas never should act as Behaviors,
they need to be able to respond according to the protocol that has been put
there for various reasons. My main concern is that all browsers will need to
keep working with the delta represenations. And from my Squeak experience it
would only be a matter of weeks before problems would arise :-)

So the current solution is ugly but for a practical reason. It is not
entirely ad hoc, if based on experience from merely one previous generation
of such implementations.

But I am not against such a refactoring, however one should weigh the gains
of adopting a more "correct" approach against the possible practical
problems.

Henrik