Hey Sven!
On 05/08/2012 11:07 AM, Sven Van Caekenberghe wrote:
Here are some quick reactions and factual corrections:
-<disclaimer> I don't want to push STON on anybody, I don't want to go on a crusade
promoting it.</disclaimer>
- please read the, much extended, paper
https://github.com/svenvc/ston/blob/master/ston-paper.md
- there are a couple of more examples in the new version of the paper
Ok, perhaps you have updated it? I thought I read it. I wrote most of
the article more than a week ago :)
- Symbols in STON are not artificially limited, there are two variants
#foo
#key-value
#FOO/1
#'foo$bar!'
#''\u00E9l\u00E8ve en Fran\u00E7ais'
Ok, perhaps I misunderstood then. I read the BNF etc, and did find some
cases which seemed to be limited but now I don't recall.
- yes, the other primitives are intentionally kept equal to JSON
- STON is already ported and being ported to other Smalltalks
Right, I wrote "probably" because I didn't know :)
- STON is now backwards compatible with JSON (both nil and null, as well as
singe and double quotes work)
That is indeed a nice approach and makes it much more attractive as an
alternative. :)
- you skipped some of the predefined representations that make life so much
easier in STON
Time['10:32:10']
Date['2012-05-08']
DateAndTime['2012-05-08T10:33:05.134+02:00']
ByteArray['F87800FF12']
Point[10,-10]
Skipped? Oh, ok, yeah. I skipped tons of stuff about Tirade too ;). But
I agree, its nice with "out of the box" utilities like the above.
- but the key point is indeed the class tag (hence the definition, STON is a
lightweight, text-based, human-readable data interchange format for class-based
object-oriented languages), your small example
IntegerArray [1, 2, 3]
vs
{"type": "IntegerArray", "data": [1, 2, 3]}
(Your ByteArray example would be ByteArray['010203'] in STON, BTW).
gives the impression that this is a small thing that is easily overcome,
Mmm, in fact, I don't really *advocate* the above - I merely wrote that
to show that we *can* do it like that. Personally I tend to think that
the reader in 99% of the cases would need to "know" what the hell it is
parsing anyway and then also knows what classes to map to.
but I strongly disagree, and that is the main reason why I want to see how far STON can go. The things is, some people will call the field
"type", others might call it "class" or "_class" or whatever, the value might be "Rectangle" or
"java.lang.Rectangle" or "geometry$rectangle". This will never be interoperable and falls out of the JSON spec.
JSON on itself is *not* self-describing: you either have to use and agree on
annotations like the above, or both parties have to agree on types externally.
JSON is *not* a serialization format. Despite all that JSON *is* successful,
which is great.
I agree in full, however contradictory that may sound. ;)
The annotation approach completely breaks down, IMHO, in terms of lightweight&
human readable, when the example becomes even slightly more complicated:
Rectangle { #origin : Point [ -40, -15 ], #corner : Point [ 60, 35 ] }
vs
{ "type" : "Rectangle", "data" : {
"origin" : { "type" : "Point", "data" : { "x" : -40, "y" : -15
} },
"corner" : { "type" : "Point", "data" : { "x" : 60, "y" : 35 }
} }
Yeah, but just let me note that my view is that:
- If you really, really want to name classes for instantiation you *can*
do it within JSON. Ugly, sure. But you can.
- In general I believe in 99% of the cases the parsing system has to
know what it is parsing, how the JSON looks and how it should be mapped
onto objects. Making the JSON parser itsy bitsy smarter with type
annotations doesn't help me there, I still need to know that I want to
instantiate a PDFPage and put this Rectangle into it - but oh, perhaps
not as a Rectangle, but perhaps as two points sent into a class side
instantiation message or something.
My point being that the type annotations doesn't "buy me" enough.
regards, Göran
