2009/3/17 Göran Krampe <goran at krampe.se>

> Hi!
>
> (snipping a bit)
>

me too

>
>
> I added TiradeStackReader, it seems quite nice.
>
>  What I can tell you is that my first scheme for saving objects trees was
>> built on such a stack pattern...
>> ...But I then switched to a syntax with file scope variables support to
>> get:
>> 1) more power (ability to save arbitrary graphs)
>> 2) readable code (I don't consider a tree spanning over several pages
>> readable)
>> 3) plenty of deprecated messages for handling stack (they don't add value
>> to
>> the API, do they ?)
>> 4) no more bytecode limitations
>> 5) a scheme that could be used to transcript (log) user graphical actions
>>
>>> From this time on, the application lived twenty years with constant
>>> upgrades
>>>
>> without file format problems.
>>
>> Again, this is probably too much for deltas, and does not meet all your
>> requirements.
>> Sure, a collection of flat objects might be more than enough.
>> But it's worth thinking twice for possible evolutions or other apps.
>>
>
> It might be worth noting that I want something simple that people can use
> with very little effort. This means cutting some corners.
>
> But I also don't want to do "plain serialization", instead I want to create
> a *custom* builder (serializers have a generic builder for all kinds of
> Smalltalk objects) that works in *tandem* with the domain objects it
> constructs (by utilizing real instance creation methods taking arguments and
> not just "basicNew" followed by stuffing ivars) and that can be driven by
> Tirade messages.
>
> The above paragraph catches it quite well I think. So construction looks
> like this perhaps:
>

Agree.
My "serialization" was customized to use higher level messages to re-build
the objects (a public API)...
...rather than lower level inst var description.
When necessary, with help of a builder (stored in a predefined file scope
variable).


>
>
> "tirade message sequence" => TiradeParser (parses) => TiradeStackReader
> (security checks and maintaining stack of receivers) => DeltaBuilder =>
> "delta domain objects"
>
> Now, a very small example:
>
> Tirade input:
> ---------------
> createDelta: 'Name of delta'.
>  addRenameClass: #OldClassName.
>    newClassName: #NewClassName.
>  end.
>  addRenameClass: #AnotherOldClassName.
>    newClassName: #AnotherNewClassName.
>  end.
> end.
> -----------------------------
>
> DeltaBuilder>>createDelta: aName
>        ^DSDelta named: aName
>
> DSDelta>>addRenameClass: oldClassName
>     "Here we return the DSClassRenameChange instance.
>     Thus it will be the stacked receiver for Tirade messages."
>     ^self addChange: (DSClassRenameChange from: oldClassName)
>
> DSClassRenameChange>>newClassName: newClassName
>     newName := newClassName
>
>
> ...ok, so the DeltaBuilder creates a Delta and returns it as the next
> receiver on the stack.
>
> Then comes another message to add a "rename class" change. (A Delta is a
> sequence of Changes basically). We do that BUT we also return this new
> DSClassRenameChange object so that it will be the next receiver.
>
> #newClassName: is thus not sent to the DSClassRenameChange object, setting
> one of its attributes. It returns self so it will still be the receiver for
> more messages. If it returned nil it would cause the TiradeStackReader to
> pop it, thus an object can actually "pop itself".
>
> More likely the Tirade input knows when we are done setting attributes so
> it sends #end. This message is a message that TiradeStackReader intercepts
> and causes it to pop the stack. The final #end pops the Delta too.
>
> Note that we are not naming ivars in the Tirade input, we aren't even
> naming the class DSDelta! Everything is a message with data as arguments.
>
> regards, Göran
>
> OK, this is cute, both syntax and implementation are simple, efficient and
readable.

I was fearing this would apply only to a collection of flat objects.
... and any deeper level would require another strategy, like using a JSON
like literal array...
... unless, each object acts as the builder for its next level in hierarchy.
Here DSDelta acts as the builder for building a DSClassRenameChange.
This is certainly a good pattern.

Thank you for explaining.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090317/f4c67736/attachment.htm