A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

Frank Shearar frank.shearar at gmail.com
Tue May 8 09:32:58 UTC 2012


On 8 May 2012 10:07, Sven Van Caekenberghe <sven at 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 at 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_upd_efined-class.html),
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
>
>
>
>
>


More information about the Squeak-dev mailing list