Avi Bryant <avi.bryant at gmail.com> wrote:
> 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.
I am very much in favor of this approach! See my reasons, reusing a mail
I sent on November, the 17th:

I suggest we use PI subclasses instead of PI instances. I find them much
better for the following reasons:
- They are more straightforward to put into the update stream. ;-)
- They are more explicit than PI instances and thus easier to
understand.
- For some packages we need to have subclasses anyway because there is a
need for overwritten messages. Using PI subclasses for all packages
reduces the number of necessary concepts by half (from two to one ;-)
and is thus easier to understand. Think STTMPW.
- With PI subclasses there is a natural place to put things for a
package, should the need arise. Think package documentation. ;-)
- The PI subclasses would be a natural place to put code for package
initialization, reinitialization, loading, unloading.
- Monticello could be more easily used for versioning and merging
package meta-information.
- They would be very similar to ENVY applications and subapplications
and thus very easy to understand for former ENVY users.
- Porting code from and to VW/Envy and VA would be easier.

Therefore, I vote for making subclasses mandatory.

Thanks for your attention!

Bernhard :-)