[ENH][Modules] Delta Modules [was: Another version]

Andreas Raab Andreas.Raab at gmx.de
Thu Oct 4 06:33:58 UTC 2001


Stephane,

Please keep in mind that I said that's how I think about it - Henrik's view
might be entirely different (I'm sure it's at least partly different ;-) so
forgive me if I can't answer all your questions. I'm not an expert; I
actually haven't done anything except asking Henrik about some of the
implications.

> Have you worked with VW and/or Envy?
> in envy this is called class extension, in envy they cannot hide pre
> existing method nor change the class definition, while in VW
> with Parcel you can hide 9and get it back on unload) a method
> and may be change the class definition I have to check,

I think that's correct. My feelings about this issue are controversial. From
one point of view, it seems inherently dangerous to allow modifications of
other classes that go beyound simply adding methods. At the point were any
modification besides adding is allowed, you are allowed to break the "API"
of that class. I'm not saying that this must be the case but it can be and
it's made easy to break the class (be that only because of a completely
unintended side effect). However, the other side of it is that modifying the
module itself might not always be practical and if there's no mechanism at
all allowing for this the entire process can become extremely painful. As an
example (we got a nice one in Squeak) take Form>>displayInterpolatedOn:
which is supposed to blow up some form in high quality. If the 3D engine is
present, then it'll use bi-linear interpolation from there; if not, it's
using WarpBlt (which still gives reasonable results). It is really unclear
to me how this should be handled in the best (read that as: simplest, most
obvious, and easy to maintain) way.

> > Delta Modules say "okay, for making this module
> > work in a given environment I need some modification
> > of x or y in a different module" and that is conceptually
> > very different from defining a set of useful classes
> > which - given the absence of the environment - could
> > perfectly well stand on their own.
>
> This is not that different, you only do not define a class.

What could be more different? ;-) On the one hand we have a set of
well-defined classes and their methods, playing nicely together. On the
other we have a number of "intruders"; classes that only need to interact
with that module because "they are there". Methods in the module have a
well-defined home, they form a well-defined algebra. Those in DMs are being
attached to "other" classes; might not even be there etc. etc. etc. How
could the two be more different?!

> But DM should be unloaded when the module they refer to unload.
> I do not really see why there is a difference between the two.
> This is just the way program are perceived and this is fun
> to see that in a world like Smalltalk where normally we can
> add method anywhere we start to do a conceptual distinction
> between class and method and method attached to other classes.

We're not making an arbitrary distinction here. The difference is inherent
because the "other classes" might not even exist.

> A module could be just a list of declaration
> (method, global, class,..... and you do not need to know
> what is DM or Module) as soon as you know what belongs to a
> module and you can load it and unload it.

It could. But at that point you're moving the complexity into the module
itself. One of the beautiful points about Henriks design (at least the way I
see it) is that a module is clean per definition. A module doesn't contain
any of the "ugly" stuff (modifications to other classes etc) so it's a
beauty in itself. If you get the module you got everything that makes it a
piece of functionality. For embedding it into the environment you need
deltas, that extend the existing environment to cooperate with the module.
No point in "messing up" a module with all that stuff. I like this idea.

> Another question
>
> I have mod1 with extensions (DM1) = String>>asUrl
>
> can I see String>>asUrl from mod2 if there are not relations
> between the two?

Good question. First of all what do mean by "see" here? Being able to send
#asUrl to String?! I think you'll be able to do this (at least Henriks last
version didn't include selector name spaces).

> I have the intuition that I should only see asUrl from a
> module only if this module depends from mod1.
>
> What is your point of view on that?

Generally, I like selector name spaces. But they can be confusing to use. I
believe that the major issue here is (as with so many others ;-) the user
interface that is provided. If there's a selector name space then we need to
make sure we see the right sub-set of selectors when looking at the object.
But I figure that's a while in the future.

Cheers,
  - Andreas





More information about the Squeak-dev mailing list