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/