Sven, Just an off-the-wall thought... If JSON were a subset of STON ... or possibly STON would recognize JSON and parse despite the different syntax...we'd have a nice multipurpose parser/writer that could speak JSON or STON interchangeably... Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <sven@beta9.be> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 10:35:49 AM | Subject: Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec) | | | On 24 Apr 2012, at 19:22, Dale Henrichs wrote: | | > Sven, | > | > I looked at your sample document in the pdf: | > | > TestDomainObject { | > #created : DateAndTime [ '2012-02-14T16:40:15+01:00' ], | > #modified : DateAndTime [ '2012-02-14T16:40:18+01:00' ], | > #integer : 39581, | > #float : 73.84789359463944, | > #description : 'This is a test', | > #color : #green, | > #tags : [ | > #two, | > #beta, | > #medium | > ], | > #bytes : ByteArray [ 'afabfdf61d030f43eb67960c0ae9f39f' ], | > #boolean : false | > } | > | > And this is very readable (to me)... not as many '[]' as I inferred | > from reading the tests:). | > | > I take back my YAML comparison ... this has the nice flavor of | > Smalltalk ... | > | > Dale | | Thanks! | | The main 'hack' is to extend JSON's list/array [] and map/dictionary | {} with a very simple way to instanciate any class, by preceding | them with a class name (or alias) and giving the control to | instanciate to the class or instance. Furthermore, for Array and | Dictionary these are optional. For the concrete representations | choosen for say DateAndTime or ByteArray, human readability was the | deciding factor. But any of these could be changed without hurting | the concept. | | Note that there are also references and implicit object counting and | graph tracing with a defined visit order. In a discussion with | Mariano I kind of decided to no longer treat Strings as | shareable/referenceable objects. This is not yet reflected in the | document but it is in the code. | | Sven |