Noury Bouraqadi a écrit :
> 
> Le 15 févr. 07 à 04:48, Robert Hawley a écrit :
> 
>> Thanks for this Noury.  The interface building side of Morphic needs 
>> this kind of thing.
>>
>> On the matter of serialisation, as alternative it would be nice (also) 
>> to be able to generate the objects from code but I don't think this is 
>> very easy.  Morphic is inconsistent between how coding works and how 
>> scripting works. (E.g. a morph responds to a forward: command in 
>> scripting but coding it involves messing around with (assuring) 
>> costumes - also the naming of components doesn't link to variable 
>> names very conveniently.)  An alternative to byte serialisation could 
>> be to generate full Smalltalk initialization code that can build the 
>> object fully from scratch - does this sort of code exist?
> 
> The idea is interesting. I'm not aware of such thing.
>  From the discussion about I think that it doesn't exist.
> 
> Noury
> ------------------------------------------------------------------
> Dr. Noury Bouraqadi - Enseignant/Chercheur
> ARMINES - Ecole des Mines de Douai - Dept. I.A.
> http://csl.ensm-douai.fr/noury
> 
> European Smalltalk Users Group Board
> http://www.esug.org
> ------------------------------------------------------------------
> 

A bad candidate is storeOn:
storeOn: is not able to handle complex object graphs...

I prototyped in VW public store a storeOn: like, named ProgramRebuilder.
It handles complex graphs, circularities etc...

You have to define a #rebuildProgramNodeOn: in each class you want to 
save (like storeOn:). Otherwise you inherit from ugly instVarAt:put: 
basicAt:put: construction messages (like storeOn:). It would be easy to 
obtain a generic version based on instVarNames setters.
The difference with storeOn: is that you build a ProgramNode (Abstract 
Syntax Tree) with help of a ProgramRebuilder. You can then use arbitrary 
messages, loops, temporaries or other constructs...

Simple example:
Complex>>rebuildProgramNodeOn: aProgramRebuilder
     ^aProgramRebuilder
         receiver: real
         selector: #+
         argument: (aProgramRebuilder receiver: imaginary selector: #i)

Unlike storeOn:, you do not have to bother with parenthesis. The AST 
printer will manage this for you.

But ProgramRebuilder does not write a single method. Due to byte code 
limits, complex object generally cannot be rebuilt in a single 
compilable method.
I used chunks and workspace variables (this was targetting saving on files).

The idea could be to replace chunk with methods, and workspace variables 
  with another pool...

Maybe something like:
object1From: pool
     	^pool at: #object1 ifAbsentPut: [" code for building object1 "]