On 20 October 2012 04:13, Igor Stasenko <siguctua@gmail.com> wrote:
On 20 October 2012 03:48, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:46:47 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | 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.
Please read my earlier description of why I think JSON is more readable as you haven't addressed the main points with this format...
yes, because i do not regarding them as significant.
| | 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.
I understand that you can read this format, but I still maintain that in the end the lack of a few syntactic elements make this format ambiguous to read/write for the human...You need to full expression to make sense of it though.
It is not the fact that the expression works evaluates correctly but the fact that the interpretation of all of the elements relies upon knowledge of the underlying implementation ... for example, I am not familiar with the Color class so:
(Color 1 1 0)
tells me nothing when I read it ... are those rgb values cyn or some other encoding the lack of the names causes me problems .... if the shape of the Color class changes, then this particular expression will be useless ... in the wild classes tend to change shape over time ...
But this is what conventions for (and conversions written to conform with conventions). I do not see a big problem here. Second, (and that's one of the reasons for not implementing generic Object>>asObjectLiteral), you can allow conversion only for certain set of classes, Point, Number, Collection(s) etc, i.e. the ones which has ~0 chance of changing shape/representation. Like in case of dictionary, we do not reflecting the shape of this class directly i.e. (tally and array ivars), but rather reflecting its data-structure, so internal representation is not very important there and hence ca be made highly portable across dialects.
Third, if you are not familiar with Color , as long as you won't start using it in some of your project(s), i cannot see what should happen to make (Color 1 0 0) appear in the data what you dealing with in your projects. From other side, for other person(s) it could be very important for them to be able to serialize colors. So they will be using it , but in their own project(s). Now since you never cross roads, i do not see how you can have any issues with that: it is not your data, therefore not your headache.
Fourth, take CSS , for example. they having three ways defining color: #rrggbb #rgb or rgb(r,g,b)
and same thing, as you may guess #75927 notation means nothing for somebody who not familiar with CSS. (he may also make a wild guess, maybe it is cyn? who knows.. ;) )
So, if you don't like (Color 1 0 0) nothing prevents you from denoting colors in more explicit way, like: (RGBColor 1 0 0) or (RGB 1 0 0) or (Color r 1 g 0 b 0 alpha 0) or whatever you see fit.
In this notation use of class names is just a cheap and fast way to for denoting the stored object. With some little code, you can use arbitrary "type name" for denoting that, it is just your responsibility to recognize it and represent it with proper object at the end. But notation form don't needs to be altered, is will still stay (<data type name> <values>) and still smalltalk syntax.
| | 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 :)
except when you sitting in a text editor or when you are in a Smalltalk dialect that doesn't have the class you are looking at or the shape of the class in that dialect is different ...
in addition to my above comment: if your goal to make data dialect neutral, you making sure it is dialect neutral (no magic ;) , either by avoiding using non-compatible data structures, or represent them in a dialect-neutral way.
Look what we actually doing with JSON: since in smalltalk we can't have native representation of JS object, we representing it with surrogate (either dictionary or instance of JSONObject class etc).
| | 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.
Regarding this goal...you realize that you are entering the territory where you have a solution (using smalltalk syntax to express data) and are looking for a problem to solve.
The problem I had (9 months ago, which was solved by using JSON/STON) is still not solved by your solution... you don't fail in terms of functionality, but in the simple fact that I value the extra syntax that STON/JSON provides that differentiates between arrays and dictionaries ...
You create a literal dictionary/object syntax for Smalltalk and you might have a convert.
In that case, i think , better would be to stay with STON then.
Dictionaries is quite complex data structure, comparing to lists (arrays) and basic values (numbers, strings and symbols). How many other languages, apart from JS, has syntax to denote dictionary-like structures?
Ruby: {:foo => 1, :bar => 2} Clojure: {:foo 1 :bar 2} Python: {'foo': 1, 'bar': 2} frank
I do not see a need in having separate syntax for dictionary. Because this goes to nowhere in form of never-ending story: - tomorrow i want syntactic sugar for Sets
Because with syntax for lists and dictionaries you can roll any kind of literal you might care for.
- then for Colors
A dictionary with keys of 'r', 'g' and 'b', Or 'c', 'm', 'y', 'k'. Or anything else.
- then for Points, Rectangles and Circles
A dictionary with 'x' and 'y' keys (or 'rho' and 'theta'), a list of four dictionaries (for the points), and a list with two dictionaries for the points.
... - and Pink Elephants
one of the reasons, why i like smalltalk syntax, is small grammar, minimal syntactic constructs, yet high expressive power. Smalltalk (and LISP) is a good demonstration that massive set of different syntax sugars/rules and expressive power are not correlating values.
Ah, but it's precisely Lisp's uniformity in appearance that trips people up. And that's precisely why in Clojure a list is (1 2 3), a vector is [1 2 3] and a dictionary is {:a 1 :b 2} - different things are visually distinct. You don't need a _lot_ of difference, because a little goes a long way. frank
If you think otherwise, i think you better start using Perl instead, where you can find sugars everywhere and will find that you can write same expression using infinite number of ways, up to the point that it is no longer possible to understand the code which you didn't wrote yourself.
| | > 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.
Igor, you are asking form my _opinion_ and I' giving you my _opinion_, and I will repeat it again, I think there needs to be a syntactic difference between dictionary and array ... only to make it possible for the poor human to make sense of things.... the lack of the syntactic demarcation is the weakness here.
I really think that your current variant is way to dependent upon magical ordering...multiple platforms do not represent common classes the same way and positional parameters don't allow for shape changes over time ... way to rigid and structured...
I think this don't needs additional comment(s) from me, since i answered to them above.
Dale
-- Best regards, Igor Stasenko.