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
