On 8 May 2012 10:07, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 08 May 2012, at 09:55, Göran Krampe wrote:
Sven - sorry for beating down a bit on STON in that article, nothing personal and I love all the stuff you have done, I just have a hard time placing STON in my toolbox. If you can give me good arguments why I am dead wrong - please do! ;)
No problem, Göran, discussion are good. No offense taken.
I will try to come back with some more feedback on your post and about Tirade once I have more time to read and think about it. But I have little time this month.
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
- Symbols in STON are not artificially limited, there are two variants
    #foo     #key-value     #FOO/1
    #'foo$bar!'     #''\u00E9l\u00E8ve en Fran\u00E7ais'
- yes, the other primitives are intentionally kept equal to JSON
- STON is already ported and being ported to other Smalltalks
- STON is now backwards compatible with JSON (both nil and null, as well as singe and double quotes work)
- 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]
- 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, 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.
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 } } }
It's worse than that in two ways: given some type Foo understood by the two ends of the connection, unless you have frozen your wire contract (the shape of things), you need to add versioning. Your types essentially become something like "Foo@1.1" meaning " a version 1.1 Foo". That implies some convention on handling types of differing version. This issue's not limited to JSON: it'll occur in any serialisation mechanism. [1] But I guess the point of []s is to indicate "this is a well-known class whose shape WILL NOT change because its meaning is as per STON, not your crazy dialect where Rectangle has a special unique shape". The second way is one you already know about: JSON is tree-like, not DAG-like, so you can either use a convention for references, or break DAGs into trees by cloning nodes. In the latter case, you then need a way of reconstructing the DAG, for instance by giving the nodes in your graph an identity (like a "_node" : <an integer> field). frank [1] This links back to a topic I've mentioned before: in CLOS you have UPDATE-INSTANCE-FOR-REDEFINED-CLASS (http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/stagenfun_...), but I'll not pursue that issue any further; it's pretty off-topic for the thread.
Granted, Point is treated special in STON, without that special treatment, it would be
    Rectangle { #origin : Point { #x : -40, #y : -15 ], #corner : Point { #x : 60, #y : 35 } }
But let me be absolutely clear: if I want to publish a REST API to talk to the outside world, I would most certainly use JSON (with externally agreed types). For me, STON, is for use between Smalltalk programs (client-server, inter-server, preference, property and configuration files, messaging, meta-info, â¦). It could work with Java, C#, Objective-C, and others.
Regards,
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill