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