PackageInfo ... where?

ducasse ducasse at iam.unibe.ch
Mon Oct 13 18:11:20 UTC 2003


>> Yes, I was proposing that we prevent overrides at load time, but 
>> perhaps that's being too restrictive.  But how else would you prevent 
>> a method from being in two packages if you allow overrides?

Hi doug
I do not understand what you mean by overrides at load-time. Do you 
mean that by loading  a package I could not
change the method definition of a method that is already there in 
another package?

> I suppose you could handle that by having a rule such as:  A method is 
> considered as "belonging" to only the PackageInfo package in which is 
> was first defined.  If another package overwrites the method, it's 
> still considered as belonging to the first package.  This might have 
> some bad effects, but it might be workable.

I do not really see why you need that rule. What is the semantics of 
the unload that you want
because if I load P2>>C>>m and it overrides P1>>C>>m then when you 
unload P2 you should have P1>>C>>m back.

I think that overrides is needed else you could not have the same 
behavior with and without packages. (or you should have a look at 
ClassBox :)) http://www.iam.unibe.ch/~scg/Research/Classboxes/index.html

>> And if we had that rule - what would we do if we really needed an
>> override?  I agree that it makes things simpler, but it's also a 
>> little
>> restrictive.  Thoughts?
>>
> If we did have the no-overrides-in-PI-packages rule, you'd have to use 
> some other "patch" file format such as .cs or something else to handle 
> overrides.  These patches would not be unloadable, but PI packages 
> would be.  (Uh oh, is this sounding too reminiscent of DeltaModules? 
> ;-) )  Maybe this is too restrictive, but as a general rule, you could 
> argue that most packages should not be patching/overwriting other 
> packages.  Non-overwriting class extensions are a different thing and 
> are relatively harmless.  There are module systems that stick to this 
> rule, anyway.

yes a lot of package system only permits addition.

>>> Hm, yeah I haven't thought about that as much.  You could have
>>> hierarchical packages, or maybe just allow a looser type of
>>> categorization for subpackages only (which would not be the same as
>>> toplevel Packages).

If you have packages as real entity then why at unload, hidden methods 
could not be reinstalled.

Methods are the easy part in fact because do you accept to redefine a 
class when you load a package.
This is much more a problem because of method offset recalculation. In 
VW you can do that and sometimes (shame on me) I use that but this is 
really bad because you end up to have to duplicate code an introduce 
hidden dependencies (shame on me). In Envy you could not change the 
shape of a class by redefining its redefinition.

But I do not see why we could not override a method definition. When 
you do need that you really need it. Or you should use classbox ;) or 
may be selector namespaces.


Stef






More information about the Squeak-dev mailing list