PackageInfo ... where?
Doug Way
dway at riskmetrics.com
Sat Oct 11 17:47:14 UTC 2003
On Saturday, October 11, 2003, at 12:44 AM, Avi Bryant wrote:
>
> On Sat, 11 Oct 2003, Doug Way wrote:
>
>> One further step that could be taken at some point (might be too
>> "aggressive" right now) would be to have a further restricted package
>> type which would be defined as a PackageInfo package is (new classes
>> plus loose methods), but it would not allow methods to be overwritten
>> upon loading. Such a package type would be trivially unloadable.
>> This
>> is roughly how Envy packages worked (and Ginsu modules, I think).
>> Unload capability would be pretty nice. :-)
>
> Something else that's worth discussing is the invariant that each
> method
> or class definition should belong to at most one package (eventually
> that
> should probably be *exactly* one package, but for now I don't think we
> should go there). Currently, that's not true for PackageInfo - for
> example, I could have both a Collections package and a Collections-Text
> package. Also, since you're allowed to subclass PackageInfo and use
> whatever rules you like, it's possible to have packages overlapping in
> crazy arbitrary ways (not just nice subset/superset relations).
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.)
I *think* this invariant is probably a good idea, for the reasons
mentioned. I think it would make things like package-savvy browsers
conceptually simpler. Plus simpler unloading. Also, I hadn't even
thought of the bug-tracking/SM aspect that Goran mentioned.
> On the other hand, the flexibility and adhoc nature of the current
> system
> has its uses as well. For example, it's convenient with MudPie to be
> able to arbitrarily choose the level at which you want to do analysis
> - do
> you want to be looking at all of Morphic as a unit, or go down into
> the subcategories? If we get stricter about packaging, we'd need to
> introduce hierarchical packages to get the same benefits.
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).
- Doug
More information about the Squeak-dev
mailing list
|