Hi Bernhard and all!

Bernhard Pieber <bernhard at pieber.com> wrote:
> goran.krampe at bluefish.se wrote:
> > We really should try getting that boat in the water though and I think
> > we simply need to figure out how we "put PI instances into the image
> > using the update stream". If we just solve that (should be easy, someone
> > just have to do it) then we can start pumping out some PIs and we can
> > easily integrate that with SM and BFAV.
> > 
> > If noone else does this I will. Now, how did this darn PI thingy work
> > now again... ;)
> 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.
> 
> So, what do others think?

Well, I must say that I agree with all your points - so it sure looks
like we should use subclasses.
If that is the case, then... we should just go ahead.

regards, Göran