DeltaModules vs Envy/Ginsu Class Extensions (was Re: Squeak Starter)

Stephane Ducasse squeak-dev at lists.squeakfoundation.org
Sat Oct 19 07:45:03 UTC 2002


Hi doug

but in parcel or packages in VW you can change override methods and t=
he=20
shape of the classes too which is really trickier.
Now you can also add conceptually a namespace to a envy applications=
=20
and you get the unload facilities, this is what was
used in VW30 to have parcel unload and automatic load. This is great=
=20
you can load the parcels in any order the prereq are loading
if they are found if one is missing at the end everyhitng is unloaded=
=20
or not installed.

> With Envy/Ginsu-style modules (which I assume are similar to what R=
oel=20
> & Steph are talking about), modules can contain classes, and can al=
so=20
> contain "Class Extensions" (a.k.a. loose methods).  I would define=
=20
> Class Extensions as methods which are additions to classes in other=
=20
> modules, but they are ONLY additions, NOT changes to existing metho=
ds=20
> (and not removals either).
>
> DeltaModules, on the other hand, can contain method additions, but=
=20
> also changes to existing methods and method removals too.





>
> So, to generalize a bit, DeltaModules are more powerful, but Class=
=20
> Extensions are quite a bit simpler.
>
> Let's think about a couple of useful properties of modules:
>
> 1. Can they be cleanly unloaded?
> 2. Are they behavior-preserving?  In other words, if you load (and=
=20
> activate) a module, will the rest of the system still run without=
=20
> breaking or behaving differently?

Yes this is a key point. We worked on something that we called classB=
ox=20
that add some nice properties but also some wrong ;)

>
> Regarding #1, 3.3a-style Modules and DeltaModules can be unloaded, =
and=20
> Envy/Ginsu-style modules can too, so no problems there.  Changesets=
=20
> cannot be unloaded, which is their big limitation.
>
> Regarding #2, this is one reason for the split between Modules and=
=20
> DeltaModules in 3.3a.  If you load a Module (with no DeltaModules),=
=20
> the rest of the system will be unaffected, so they are=20
> behavior-preserving. DeltaModules are not behavior-preserving, but=
=20
> that's the point of them... they can be used if you do need to chan=
ge=20
> something else in the system.
>
> Because DeltaModules are not behavior-preserving, they naturally ha=
ve=20
> to change version numbers of the Modules that they modify.  So for=
=20
> example if a WebBrowser Module has a DeltaModule which adds the met=
hod=20
> #asEncodedHtml or changes a method in class String, in the Module=
=20
> "Kernel 2.7", the Kernel module will need to be assigned a new vers=
ion=20
> number such as 2.8.  (I believe this is how DeltaModules are suppos=
ed=20
> to work, correct me if I'm wrong.)  This may have big implications =
for=20
> the rest of the modules in the system, which might expect to run on=
=20
> Kernel 2.7 but not know about 2.8.
>
> But the interesting thing is, Envy/Ginsu-style modules w/Class=20
> Extensions *are* behavior-preserving, with a few caveats* (see bott=
om=20
> of message).  This is because, in general, if you add a new method =
to=20
> an existing class, none of the rest of the system would ever send t=
hat=20
> new method, so the behavior of the rest of the system is unchanged.=
 =20
> So, reusing the example above, if a WebBrowser module has a Class=
=20
> Extension which adds the method #asEncodedHtml (but does not change=
=20
> any method) in class String, in the module "Kernel 2.7", the Kernel=
=20
> module will still remain 2.7.  (This is exactly what Envy does.  I=
=20
> don't remember now if Ginsu supports version numbers.)

Exact we try to see how a class extension could be only working for t=
he=20
module that define it but in case of method modification
that the system only calls your modification when you were invoking t=
he=20
other methods that would call the method you changed.
It worked but we were not satisfied. Roel cna explain that at OOPSLA


>
> The other question is then, if we're using Class Extensions, is it=
=20
> good enough to only be able to *add* methods to classes in other=
=20
> modules, not modify/remove them (as DeltaModules can do)?
>
> Well, I guess that's a big question. :-)  I would say that most of =
the=20
> time, yes, it's good enough.  A module does not often need to=20
> change/remove methods in other modules, unless we're directly fixin=
g a=20
> bug in that other module.  Adding methods is much more useful, and =
can=20
> be specific to the "outer" module (such as the example WebBrowser=
=20
> module adding #asEncodedHtml to String).  People who've used Envy k=
now=20
> that it can be very handy... although you don't want to abuse it to=
 an=20
> extreme


>
> With Envy/Ginsu, if your module *really* needs to change/remove a=
=20
> method in Kernel 2.7, you make your own private version of Kernel 2=
.8=20
> with the change, and/or you lobby the maintainer of Kernel to make =
the=20
> change. But this should be relatively rare aside from bug fixes.
>
> On the other hand, the ability of DeltaModules to handle method=
=20
> changes/removals could be quite nice.  And they seem a bit more=
=20
> rigorous, no "caveats" as with Class Extensions below.  And namespa=
ces=20
> are already built-in.  But there is extra complexity cost...  For=
=20
> example, DeltaModules have to worry about activation/deactivation,=
=20
> with Class Extensions it is irrelevant.  The Class Extensions are=
=20
> always active when the module is active, since they don't affect=
=20
> anything else.


I think that supporting modification of methods is cool but makes=
=20
things much more complex. Same for changing the shape of a class.

>
> One last thing: As far as splitting up the current Squeak image int=
o=20
> modules goes, my hunch is that it would be easier to do with=20
> Envy/Ginsu-style modules.  This is because you would not need the=
=20
> DeltaModule capability of specifying changed/removed methods when=
=20
> divvying things up, only the ability to specify added methods, whic=
h=20
> the lighter-weight Class Extensions can also handle without version=
=20
> number worries.  For example, String>>asMorph could be quickly dump=
ed=20
> into some Morphic module.
>
> (Avi, are the DVS "logical modules" similar to Envy/Ginsu with Clas=
s=20
> Extensions?)
>
> Am I making sense here?  This message is getting too long, sorry.  =
Let=20
> me know if I've characterized one of the approaches incorrectly.  A=
nd=20
> I know this is only one aspect of the differences between these two=
=20
> module systems.  Anyway, I've often found that I learn more by see =
two=20
> things compared against each other, than by seeing them described=
=20
> separately.
>
> - Doug Way
>  dway at riskmetrics.com

It does


>
>
>
> *Caveat #1: There could be namespace conflicts with Class Extension=
s,=20
> which Envy/Ginsu don't handle.  I'm guessing that adding namespace=
=20
> support is one thing that Roel & Steph were working on?

Yes I can send you a so not good paper :)

>
> *Caveat #2: Ideally, to preserve behavior, you would not allow a Cl=
ass=20
> Extension to override a method in a superclass.  This would be a=
=20
> simple restriction to add.  Otherwise, you could bring an image to =
its=20
> knees by adding a new method #size to SortedCollection which return=
s=20
> nil. :-)


this is price for freedom
>
> *Caveat #3: If a base module class is doing something funky with=
=20
> reflection such that adding a new method changes its behavior, then=
=20
> the Class Extension might not be behavior-preserving.  But this fal=
ls=20
> under the category of Very Rare, IMHO.  (I guess an example might b=
e=20
> adding a testXXX method to an SUnit test suite class.)
>
>
>
Dr. St=E9phane DUCASSE (ducasse at iam.unibe.ch)=20
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes





More information about the Squeak-dev mailing list