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