On Sat, 12 Feb 2005 17:32:18 -0400, Lex Spoon <lex at cc.gatech.edu> wrote:

> So, my proposal is:
> 
>         1. Move ahead with PackageInfo.
> 
>         2. Add some minor descriptive info to PackageInfo, like "description",
> and maybe a url for more info.  It would be great for these to be there.
>  The description should be a Text, ideally, just like class comments.
> 
>         3. Add some sort of variable, which optionally refers to a SqueakMap
> package corresponding to that PackageInfo.  I defer to Goran for what
> kind of info should go there, but the idea is, so long as the tools know
> which PackageInfo goes with which SqueakMap package, the tools can do
> all the same smart things they could do if PackageInfo were the *same*
> as a SqueakMap package.

Just to inject something into the discussion: originally, PackageInfo
required a subclass for each package.  To get the default behavior, it
didn't have to do anything but sit in the correct class category, but
you could override things like #packageName and so on if you wanted. 
I ended up removing this requirement because it seemed a little
heavyweight to create a whole PackageInfo subclass for every small
package.

However, one advantage of doing it that way is that it provides an
obvious place to hang things like package comments, and potentially
lots of other interesting metadata (like how to access the
corresponding SM package).  It also provides a nice declarative form
of the package declaration - ie, it makes it extremely obvious how you
add a PI to the update stream.  So maybe we should think about making
those subclasses, if not mandatory, at least a strongly encouraged
best practice.

Avi