On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
It's not clear that I need to be part of this discussion.
If you want to invent a new serialization format, then go for it.
I did chime in with my opinion that your suggested format was not very readable. You happen to disagree with me.
Yes, i disagree. Tell me what is not readable in this: #( Dictionary yellow (Color 1 1 0) blue (Color 0 0 1) red (Color 1 0 0) ) fromObjectLiteral. this is human-written object literal. It took me very little effort to express correctly the data structure i need to get out of it, with little chance of doing some syntax mistake. For smalltalker, like me, i find this expression is natural and straightforward to read. And do not discount the environment where people working in: it is smalltalk. So, even if i not understand what is inside, i can always select that piece of code and press Cmd-I to inspect it (or explore it) and then i will see everything very clear :) As well, as you can do reverse: you can craft a complex thingy, and then send #asObjectLiteral and after some prettyfying, you can make it clearly readable. (not mentioning that you can of course pretty-print it automatically). While with JSON, if you evaluate json code in JS, you will get same JSON as response.. which is cool, because of invariant, but won't make it easier to understand by any bit.
That's fine.
I also mentioned that YAML is a standard format that is designed to be very readable by humans while still being parsable by a machine. You told me that I was missing the point.
yes, because my intent was to use smalltalk syntax (so that we reusing existing codebase, and keep uniformity, which is also important).
That's fine.
You told me that the point is that you can encode arbitrary objects in literal arrays and that this representation is optimizable by the compiler.
right, but that's a side effect (which i discovered discussing here btw). I didn't had that in mind nor putting that as a requirement of design. Still, admit, that this side effect is quite nice :)
That's nice, but it is still not readable by humans (in my opinion) and I don't want to involve the compiler ... I don't want to execute code directly from the repository - I want to insert a parser, so that we have control over the code that gets executed.
i know. But my implementation does not evaluating any new code: it just parses the input and transforms it into objects. It doesn't installs new behavior to system. If you don't trust me, you're free to debug the code to see what it does.
Obviously the goals that you have for this notation do not match up with the requirements that I have.
my goal is just one: use smalltalk syntax to express data. If you take smalltalker who knows smalltalk and nothing else, i think he will learn to read that notation much faster comparing to learning JSON/STON/YAML first. Because it is already smalltalk and needs just a slight shift in POV to see through braces. That's the main point.
That's fine.
I am not in dire need of "yet another Notation format". STON adequately fills the bill for what I need at the moment.
I have responded to Eliot with more detail about why I consider JSON to be more readable than your original suggestion. I haven't commented on the readability of your other suggestions because I am assuming that you don't have code written to actually parse the different variations that you proposed.
Sooo, it's not clear that I can contribute much more.
Dale i value your contribution. You know we can criticize and fight to death. But when i demonstrated that you can use #( Dictionary a -> b) instead of #( Dictionary a b) notation, i actually wanted your input from different perspective: if we going to introduce a smalltalk-based notation (one that using smalltalk syntax), is proposed variant good enough, or there can be alternative(s), which may be better than proposed. As i said, i didn't wanted to contrast it with JSON, and derail the whole thing into fight between camps with zero value for community.
Dale
-- Best regards, Igor Stasenko.