Sven, Everybody needs a help from a parser to get formated input right ... I rely on sytax highlighting when I write Smalltalk code:), but I'd say the lack of key/value syntax is more than "a bit worse" for readability. I don't spend a lot of time reading/writing STON files but when I do...I read more often than write and with syntactic key/value demarcation I can read a dictionary with reasonable certainty and make minor edits with confidence (with or without formatting help)... with an undifferentiated list of key value pairs ... forget it:), especially when there are much more readable alternatives available. Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <sven@stfx.eu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 8:29:07 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | Dale, | | We have a web app where users sometimes have to enter some short | pieces of JSON - because we were lazy and did not provide a proper | interface ;-) You wouldn't believe in how many ways they make | syntax errors and don't understand it ! | | Alternating key value elements is not that worse than key:value or | key->value IMO, but it is a bit worse, agreed. The advantage is that | you don't need extra syntax/semantics. | | Also, we could agree on | | #(#Time '15:24:01Z') | #(#Date '2012-10-19') | #(#DateAndTime '2012-10-19T15:24:01Z') | | with dashed and colons being optional. | | Sven | | BTW: Is the # in front of Symbols needed ? | | On 19 Oct 2012, at 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... | > | > 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. | > | | > | | |