[Modules] DeltaClass
Stephen Pair
spair at advantive.com
Tue May 7 13:18:48 UTC 2002
Ok, this seems fair enough. I hadn't thought about the issue of
allowing these things to be visible in the browsers.
- Stephen
> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On
> Behalf Of Henrik Gedenryd
> Sent: Tuesday, May 07, 2002 7:56 AM
> To: squeak-dev
> Subject: Re: [Modules] DeltaClass
>
>
> 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
>
>
>
More information about the Squeak-dev
mailing list
|