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
|