Alexandre, Could? Certainly. However... At the time and possible even now, one would have to write a parser to parse that format (using the compiler and executing code is not allowed for security reasons). Portability was also a concern and GemStone does not have a public Smalltalk parser. A JSON parser consisting of 27 methods was already in existence (very portable - runs on 7 different Smalltalk dialects and counting) , so it was a no-brainer to choose JSON... It is now 9 months after the original decision and an acceptable substitute based on literal arrays has yet to come into existence. OTOH, STON _has_ appeared on the scene and it is preferable to JSON, since arbitrary classes of objects beyond Dictionary, Array, etc. can be easily (and clearly) written to disk. Moving forward I will be using STON. In the end I am a consumer ... I am not interested in writing my own parser/writer .... I don't have the aversion to the J in JSON that some folks seem to have ... I've got bits on disk that can be manipulated by humans and machines ( ... does it really matter what the bits look like? REALLY matter?) Dale ----- Original Message ----- | From: "Alexandre Bergel" <alexandre.bergel@me.com> | To: "Pharo-project@lists.gforge.inria.fr Smalltalk" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 10:20:04 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | Hi Dale, | | I have followed this issue from very very far, so I may miss | something important.\ | | > { | > "category" : "Topez-Client-Core", | > "classinstvars" : [ | > ], | > "classvars" : [ | > ], | > "commentStamp" : "", | > "instvars" : [ | > "project", | > "package", | > "currentClass", | > "classOrInstance", | > "category", | > "selector", | > "history", | > "currentWindowId", | > "windows", | > "namedWindows" ], | > "name" : "TZTopezStatus", | > "pools" : [ | > ], | > "super" : "Object", | > "type" : "normal" } | | Could not it be | | #( (category 'Topez-Client-Core') (classinstvars ) (classvars ) | (commentStamp '') (instvars 'project' 'package') (name | 'TZTopezStatus') (pools ) (super 'Object') (type 'normal')) | | Like this, no parser at all is required. | By the way, why keep pools? should type be specified in case it is | normal? | | Cheers, | Alexandre | | | > | > which brings us back to were we started. | > | > Smalltalk does not have a literal syntax for dictionaries. While | > fabricating dictionaries from literal arrays is possible, the | > results are not very readable ... unless you start taking | > liberties with Smalltalk syntax... | > | > If you are no longer restricting yourself to Smalltalk syntax, then | > what's wrong with the STON notation above? | > | > Dale | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Friday, October 19, 2012 9:10:26 AM | > | Subject: Re: [Pharo-project] Yet another Notation format: Object | > | literals | > | | > | On 19 October 2012 16:55, Dale Henrichs <dhenrich@vmware.com> | > | wrote: | > | > Igor, | > | > | > | > I'm afraid that your notation is not very friendly to humans | > | > ... a | > | > computer can keep track of the key value pairs in the literal | > | > dictionary, but a human will fail very quickly... | > | > | > | > The appeal of JSON (and STON) is that the output is readable by | > | > mere mortals: | > | > | > | > (JavaScript Object Notation) is a lightweight | > | > data-interchange format. It is easy for humans to | > | > read and write. | > | > | > | > What we're missing from Smalltalk is a literal dictionary or | > | > literal map syntax ... without that I'm afraid that for human | > | > friendly, lightweight notations we have to step away from the | > | > Smalltalk syntax - STON does this very nicely BTW... | > | | > | no problem, Dale. | > | What symbol you want to have to separate keys from values? | > | is '->' ok? | > | | > | Dictionary>>asObjectLiteral | > | | > | "convert a receiver into an object literal " | > | | > | ^ Array streamContents: [:stream | | > | stream nextPut: self class name. | > | self keysAndValuesDo: [:key :value | | > | stream | > | nextPut: key asObjectLiteral; | > | nextPut: #->; | > | nextPut: value asObjectLiteral ] ] | > | | > | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | > | | > | #(#Dictionary | > | #a #'->' #b | > | #c #'->' #d) | > | | > | which if you pretty-print will look like: | > | | > | #( | > | Dictionary | > | a -> b | > | c -> d | > | ) | > | | > | is it better? | > | or you prefer this one: | > | | > | #( | > | Dictionary | > | (a -> b) | > | (c -> d) | > | ) | > | | > | you can do anything you like, by implementing the conversion | > | methods | > | in a way you like :) | > | | > | > | > | > Dale | > | > | > | > ----- Original Message ----- | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | > | > | Sent: Friday, October 19, 2012 4:09:22 AM | > | > | Subject: [Pharo-project] Yet another Notation format: Object | > | > | literals | > | > | | > | > | Hi, | > | > | as i promised before, here the simple smalltalk-based literal | > | > | format. | > | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | > | > | needs | > | > | to | > | > | have separate parser (a normal smalltalk parser used for | > | > | that). | > | > | | > | > | The idea is quite simple: | > | > | you can tell any object to represent itself as an 'object | > | > | literal' , | > | > | for example: | > | > | | > | > | (1@3) asObjectLiteral | > | > | --> #(#Point 1 3) | > | > | | > | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | > | > | | > | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | > | > | | > | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | > | > | asObjectLiteral | > | > | -> | > | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | > | > | | > | > | Next thing, you can 'pretty-print' it (kinda): | > | > | | > | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | > | > | printObjectLiteral | > | > | | > | > | '#(#Dictionary | > | > | 1 | > | > | (#Array 1 2 3) | > | > | ''foo'' ''bar'')' | > | > | | > | > | | > | > | and sure thing, you can do reverse conversion: | > | > | | > | > | '#(#Dictionary | > | > | 1 | > | > | (#Array 1 2 3) | > | > | ''foo'' ''bar'')' parseAsObjectLiteral | > | > | | > | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | > | > | | > | > | Initially, i thought that it could be generic (by | > | > | implementing | > | > | default | > | > | Object>>#asObjectLiteral), | > | > | but then after discussing it with others, we decided to leave | > | > | | > | > | Object>>#asObjectLiteral to be a subclass responsibility. | > | > | So, potentially the format allows to represent any object(s) | > | > | as | > | > | literals, except from circular referencing objects, of | > | > | course. | > | > | | > | > | The implementation is fairly simple, as you may guess and | > | > | contains no | > | > | new classes, but just extension methods here and there. | > | > | | > | > | Take it with grain and salt, since it is just a small proof | > | > | of | > | > | concept. (And if doing it for real it may need some changes | > | > | etc). | > | > | Since i am far from areas right now, where it can be used, i | > | > | don't | > | > | want to pursue it further or advocate if this is the right | > | > | way to | > | > | do | > | > | things. | > | > | Neither i having a public repository for this project.. | > | > | | > | > | So, if there anyone who willing to pick it up and pursue the | > | > | idea | > | > | further, please feel free to do so and make a public | > | > | repository | > | > | for | > | > | project. | > | > | | > | > | | > | > | -- | > | > | Best regards, | > | > | Igor Stasenko. | > | > | | > | > | > | | > | | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | | > | | > | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | |