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

Göran Krampe goran at krampe.se
Tue May 8 11:29:04 UTC 2012


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


More information about the Squeak-dev mailing list