Hi Avi, everyone.

First of all, I really agree with the need you expressed to get more
package tool support in the image. I think this is the important thing -
changing PackageInfo, per se, is not a goal - it is a means. We should
change it only to the extent that that is the simplest way to obtain a
result we want. PackageInfo itself is rather recent, and we should
amortize its introduction costs over as much usage as we can get away
with - until it in itself begins to bother us. And it looks to me like
we're still at a point where most of the things we want really are about
missing tool support, not about limitations in PI. 

What do I mean by that? I mean that if we want to enforce some policies
about overriding/recategorizing code when loading it, this can be
provided by tools that catch and handle such events. Ginsu's loading
mechanisms were designed to do this by raising exceptions and letting
higher level tools handle them. We need something like that, and to make
some convinient ways for users to control the levels of warning they
wish to recieve. For example, I'd like to know whenever a new package I
load overrides an existing method that contains the same code.

Andreas' request falls along the same lines - obviously a tool support issue.

[Hierarchial packages/"each code element is in one package"]
For most package distribution purposes as we know them at the moment, be
able to have a method belong to more than one package definition is a
hassle. However, those can probably be dealt with as in the previous
paragraph - as tool issues - without adding a hard constraint. We might
in the future find it useful to have more flexible ideas of packages, as
we add different modes of sharing. So I think adding hard constraints
(and then additional concepts such as hierarchial packages), unless a
precise need for that is shown, is probably premature.

Daniel

Avi Bryant <avi at beta4.com> 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).
> 
> This makes it hard to do a reverse lookup - given a method, find which
> package it belongs to.  This is something Goran wants for various
> SM-related tools, and would also be useful in a few other contexts.
> 
> 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.
> 
> So what do folks think?  Is it time to tighten up PackageInfo?  How can we
> do that without breaking (or should we break) its lightweight nature?
> 
> Daniel, I'm expecting at least you to weigh in on this one. ;)
> 
> Avi