<br><br><div class="gmail_quote">2009/3/17 Göran Krampe <span dir="ltr"><<a href="mailto:goran@krampe.se">goran@krampe.se</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi!<br>
<br>
(snipping a bit)<div class="im"></div></blockquote><div><br>me too <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
</div><div class="im">
<br></div>I added TiradeStackReader, it seems quite nice.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What I can tell you is that my first scheme for saving objects trees was<br>
built on such a stack pattern...<br>
...But I then switched to a syntax with file scope variables support to get:<br>
1) more power (ability to save arbitrary graphs)<br>
2) readable code (I don't consider a tree spanning over several pages<br>
readable)<br>
3) plenty of deprecated messages for handling stack (they don't add value to<br>
the API, do they ?)<br>
4) no more bytecode limitations<br>
5) a scheme that could be used to transcript (log) user graphical actions<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>From this time on, the application lived twenty years with constant upgrades<br>
</blockquote>
without file format problems.<br>
<br>
Again, this is probably too much for deltas, and does not meet all your<br>
requirements.<br>
Sure, a collection of flat objects might be more than enough.<br>
But it's worth thinking twice for possible evolutions or other apps.<br>
</blockquote>
<br></div>
It might be worth noting that I want something simple that people can use with very little effort. This means cutting some corners.<br>
<br>
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.<br>
<br>
The above paragraph catches it quite well I think. So construction looks like this perhaps:<br>
</blockquote><div><br>Agree.<br>My "serialization" was customized to use higher level messages to re-build the objects (a public API)...<br>...rather than lower level inst var description.<br>When necessary, with help of a builder (stored in a predefined file scope variable).<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
"tirade message sequence" => TiradeParser (parses) => TiradeStackReader (security checks and maintaining stack of receivers) => DeltaBuilder => "delta domain objects"<br>
<br>
Now, a very small example:<br>
<br>
Tirade input:<br>
---------------<br>
createDelta: 'Name of delta'.<br>
addRenameClass: #OldClassName.<br>
newClassName: #NewClassName.<br>
end.<br>
addRenameClass: #AnotherOldClassName.<br>
newClassName: #AnotherNewClassName.<br>
end.<br>
end.<br>
-----------------------------<br>
<br>
DeltaBuilder>>createDelta: aName<br>
^DSDelta named: aName<br>
<br>
DSDelta>>addRenameClass: oldClassName<br>
"Here we return the DSClassRenameChange instance.<br>
Thus it will be the stacked receiver for Tirade messages."<br>
^self addChange: (DSClassRenameChange from: oldClassName)<br>
<br>
DSClassRenameChange>>newClassName: newClassName<br>
newName := newClassName<br>
<br>
<br>
...ok, so the DeltaBuilder creates a Delta and returns it as the next receiver on the stack.<br>
<br>
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.<br>
<br>
#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".<br>
<br>
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.<br>
<br>
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.<br>
<br>
regards, Göran<br>
<br>
</blockquote><div>OK, this is cute, both syntax and implementation are simple, efficient and readable.<br><br>I was fearing this would apply only to a collection of flat objects.<br>... and any deeper level would require another strategy, like using a JSON like literal array...<br>
... unless, each object acts as the builder for its next level in hierarchy.<br>Here DSDelta acts as the builder for building a DSClassRenameChange.<br>This is certainly a good pattern.<br><br>Thank you for explaining.<br>
<br>Nicolas<br></div></div>