Ned can you clarify why you want to have PI and packages?
I'm confused.



> On Thursday 17 February 2005 11:43 am, stéphane ducasse wrote:
>> On 17 févr. 05, at 20:02, Ned Konz wrote:
>>> On Thursday 17 February 2005 10:24 am, stéphane ducasse wrote:
>>>> Yes this is my mistake because we were talking about that with alex
>>>> and
>>>> I did not
>>>> check the latest version. If we use package instance this means that
>>>> we
>>>> should attacj
>>>> block like in VW. Was what your proposal?
>>>
>>> There may be issues with actually serializing and deserializing 
>>> blocks,
>>> though.
>>
>> how did you see that in your approach because as soon as you have
>> package as instances of Packages
>> then you want a way to describe postload and preload. May be storing
>> block strings is enough?
>> but this requires to have the compiler at load-time (which for the
>> beginning can be ok).
>
> If we're talking about packages that contain source code, then we could
> reasonably assume that the compiler was available, right?
>
> I'd figured that the preload and postload could be handled by PI 
> subclass
> methods that would be compiled first, or by doit strings. The first is 
> more
> manageable with existing tools.
>
> However, to do it without requiring two passes over the source code to 
> pick
> out the appropriate methods, we could package the PI subclass code 
> separately
> from the actual package code.
>
> For instance, an MCZ file could contain the following members:
>
> package (existing, but data could also be in packageInfo)
> version (existing, but data could also be in packageInfo)
> snapshot/source.st (existing, but wouldn't contain PI subclass 
> preinstall
> code)
> snapshot/preinstall.st (new, contains only code for PI subclass 
> preinstall
> methods, if any)
> packageInfo (new, serialized PI instance data)
>
> Any other PI code besides preinstall could live in the regular 
> source.st
> member.
>
> So the procedure for loading one of these would be:
>
> * read package and version files as we do now, if they're there (I see 
> this as
> backwards compatibility). Or we could put their data into packageInfo 
> but
> then we lose backwards compatibility.
> * PackageInfo class method deserializes packageInfo member into 
> PackageInfo
> instance. That instance also contains the name of the desired 
> PackageInfo
> subclass, if any.
> * that instance is used to supply package-level and version metadata
> * on load, we compile snapshot/preinstall.st if it exists.
> * Then (if the desired PI subclass class exists) we change the class 
> of the PI
> instance to the new PI subclass (or construct a new instance of the 
> desired
> class), and call any preinstall method that it may have (which would 
> have
> come from snapshot/preinstall.st).
> * Then we compile snapshot/source.st
> * and then we call any initialize methods that the classes in the 
> package may
> have had (this is done from the code in snapshot/source.st).
>
> -- 
> Ned Konz
> http://bike-nomad.com/squeak/
>
>