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