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

Sven Van Caekenberghe sven at beta9.be
Tue May 8 09:07:08 UTC 2012


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 } } }

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