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