<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!<div class="im"></div></blockquote><div><br>First, thank you for sharing this work and your thoughts, that's interesting.<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;">
<div class="im"><br>
<br>
Nicolas Cellier wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/3/16 Göran Krampe <<a href="mailto:goran@krampe.se" target="_blank">goran@krampe.se</a>><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>
Nicolas Cellier wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Goran,<br>
Two remarks:<br>
<br>
1) closing the language:<br>
<br>
I know you want control and security.<br>
<br>
</blockquote>
Well, I want to maintain simplicity mainly. Currently it is so simple that<br>
it is "intuitively safe". Safety is not necessarily about exploits but<br>
rather about not inviting developers to do "smart stuff" that breaks tools<br>
etc.<br>
<br>
But are you sure the language is opened enough for future deltas<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
extensions?<br>
<br>
</blockquote>
Can't really see what you mean.<br>
</blockquote>
<br>
The fact that you need a special interpretation of -> makes me suspicious.<br>
</blockquote>
<br></div>
The reason for #-> being handled differently is because #-> is in fact in Smalltalk implemented in Object:<br>
<br>
-> anObject<br>
"Answer an Association between self and anObject"<br>
<br>
^Association basicNew key: self value: anObject<br>
<br>
<br>
...it is thus not a literal syntax - which some may mistakenly believe!<br>
<br>
BUT... in Tirade we don't allow expressions (messages to objects and using their results), but we really want a syntax to create Associations (and thus Arrays of Associations which easily can be turned into a Dictionary by the builder).<br>
<br>
So this led me to implement the syntax <something> "->" <somethingelse> in the TiradeParser, "mimicking" Smalltalk. This is btw also a reason for choosing "brace arrays" because regular Array syntax in Smalltalk does not evaluate any expressions inside the Array, leading to this:<br>
<br>
#('key'->'value') ==> #('key' #'->' 'value')<br>
<br>
...but {'key'->'value'} works fine.</blockquote><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>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Can you tell you won't ever need 1/2 for example?<br>
</blockquote>
<br></div>
Yes, I can tell you that. :) You can create tons of "nice things to have" but if you really think about it there are a lot of ways already in Tirade to avoid adding support for "expressions" like that, for example, simply make sure to send a message that knows that the argument is a mathematical expression that the builder can evaluate:<br>
<br>
mathematicalExpression: '1/2'<div class="im"><br>
</div></blockquote><div><div class="im"><br>
</div>
I understand you added a syntax for Associations because you need some Associations NOW in delta...<br>.. Or maybe for imitating JSON structures...<br>But to me, above sentence is heavy (pathological?) for such a simple thing as a Fraction.<br>
It's like writing some C code: Cat aCat; /* this is a cat */ ;)<br>Of course, Fraction might probably not be a problem for deltas for few next years, but i want to explore other possible applications of your ideas :)<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;"><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;">
I mean representing arbitrary deep oject trees (not speaking of general<br>
graphs).<br>
The example you are presenting seems flat. Could you expose how you would<br>
build a deeper object?<br>
</blockquote>
<br></div>
Sure, either you build depth in "nested data":<br>
<br>
structure: {'key'-> {<br>
'a'->12.<br>
'b'->13'.<br>
'c'-> {<br>
'd'->{123. 345. 567}.<br>
'e'->12}}}<br>
<br>
...and let the builder create whatever objects it likes given that data.<br>
</blockquote><div><br>Sure, VW GUI specs did (do?) use this kind of scheme...<br>You have sort of JSON in Smalltalk Array Literal, maybe more powerfull because you can even intermix unary messages.<br>{'MyObject' 'a'->0. 'beAGoodObject'}.<br>
It might event be possible to use n-ary.<br> I guess you ommitted class names in above hierarchy by accident...<br>But then it's kind of troubling to have a Date string syntax in JSON syntax in Tirade syntax in Smalltalk.<br>
Doesn't that deserve more thoughts ?<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>
Or more likely you build depth by using a message protocol that shows what you are doing, for example using a stack protocol or whatever:<br>
<br>
createInstanceOf: #Animal.<br>
name: 'Tiger'.<br>
description: 'Striped animal'.<br>
addInstanceOf: #Leg.<br>
name: 'left front'.<br>
endInstance.<br>
addInstanceOf: #Leg.<br>
name: 'left front'.<br>
endInstance.<br>
addInstanceOf: #Leg.<br>
name: 'left front'.<br>
endInstance.<br>
addInstanceOf: #Leg.<br>
name: 'left front'.<br>
endInstance.<br>
endInstance.<br>
<br>
(this was one reason I added indentation support in the writer, to give hints about structure and depth that actually is not there syntactically, but only semantically)<br>
<br>
...then we can implement a builder for this:<br>
<br>
createInstanceOf: aClassName<br>
"Create an instance of given class and put on top of stack."<br>
stack push: (Smalltalk at: aClassName) new<br>
<br>
<br>
endInstance<br>
"Pop current object."<br>
stack pop<br>
<br>
<br>
addInstanceOf: aClassName<br>
| obj |<br>
obj := (Smalltalk at: aClassName) new.<br>
stack top add: obj. "add the Leg to the Animal"<br>
stack push: obj "push Leg on stack"<br>
<br>
name: aString<br>
"Yeah, we can use DNU to cover these."<br>
stack top name: aString<br>
<br>
description: aString<br>
"Yeah, we can use DNU to cover these."<br>
stack top description: aString<br>
<br>
...Also, if any of the above messages return another object instead of the builder (self) - that will be the receiver of the next Tirade message. But in order for #endInstance stuff to work we can't return a domain object as the receiver of the next Tirade message (to receive #name: and #description: directly) because it will not understand #endInstance and it does not have access to the builder object nor the stack etc.<br>
</blockquote><div><br>Yes, but nothing above tells to store the Leg object in the leg slot of the Animal.<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>
Mmmmm, but... well, we could actually let the *TiradeReader* implement some Tirade messages to maintain the stack of objects that are meant to receive the Tirade messages. Aaaahhh. Then we let the reader implement a stack of receivers instead of just "let the result of this Tirade message be the receiver of the next Tirade message". Cool, definitely a useful kind of "reader".<br>
<br>
Ok, I will add some of these examples - but to answer your question - it is quite easily done. :)<br>
<br>
regards, Göran<br>
</blockquote><div><br>
With DNU and other tricks, this might be doable, I trust your talent, and i am impatient to read your next solution.<br><br>
What I can tell you is that my first scheme for saving objects trees was 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 readable)<br>
3) plenty of deprecated messages for handling stack (they don't add value to 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>From this time on, the application lived twenty years with constant upgrades without file format problems.<br>
<br>
Again, this is probably too much for deltas, and does not meet all your 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>
<br>Nicolas
<br></div></div><br>