Hi

we discussed with avi and he is thinking for MC to get real packages in 
the future
so this may be also a good opportunity to have a cool packaging system 
for squeak.

Stef

On 18 nov. 04, at 07:23, goran.krampe at bluefish.se wrote:

> 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
>