PackageInfo ... where?

Doug Way dway at riskmetrics.com
Mon Oct 13 17:37:45 UTC 2003


Avi Bryant wrote:

>On Sat, 11 Oct 2003, Doug Way wrote:
>  
>
>>Yes, this is what I was getting at above.  Methods could not be
>>overwritten when loading a PackageInfo package because of the invariant
>>that says each method (or class definition) can belong to one package
>>at most.  (This assumes that the entire image is partitioned into
>>packages.)
>>    
>>
>
>So you're proposing we prevent overrides at load time?  This isn't
>practical for normal fileOuts; it could be a rule in Monticello, but on
>the other hand Monticello handles them somewhat gracefully anyway.
>  
>
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?

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.

>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.

>>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).
>>    
>>
>
>Can you elaborate on this?
>

I was just brainstorming there.  You could have a weaker type of 
subpackage simply for the purpose of categorizing code, which would 
allow all sorts of overlapping, but wouldn't have the restriction of 
only-one-package-per-method.  But you'd still have the 
only-one-package-per-method for the toplevel package... toplevel meaning 
a package on SM for example.  Eh, this is sounding somewhat complicated 
and is probably a bad idea.

- Doug




More information about the Squeak-dev mailing list