----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:09:18 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:26, Dale Henrichs <dhenrich@vmware.com> wrote: | > Ah, | > | > So you are asking whether I think this: | > | > {1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}} | > | > is more readable than this: | > | > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 | > #(#Array 1 2 3))) | > | > My answer is that I find the JSON style more readable. | > | > With JSON, I can look a sequence from the middle of the character | > sequence and recognize the syntactic elements: | > | > 'foo': bar', 3 | > | > as a key/value pair (foo/bar) and that 3 is probably a key ... | > while the following sequence is not recognizable as anything: | > | > 'foo' 'bar' 3 | > | > is it 3 elements in an array? is foo, bar or 3 a key? To get it | > right I have to count the key value pairs from the beginning of | > the dictionary, something that only a machine can do or a human | > presented with a small list of elements to look at. | > | > This readability is important when looking at larger structures | > that may span a screen full of items in a text editor. | > | > The {} delimiting a dictionary allows me to recognize the following | > sequence: | > | > 3]} | > | > as the end of an array and a dictionary whereas the following | > sequence could mean anything in the literal Smalltalk array world: | > | > 3)) | > | > I can use a text editor to find the terminator for a dictionary or | > an array. With a smalltalk literal array it isn't possible..again | > the human must resort to careful counting. | > | > I wouldn't think that I would need to point out that the | > #Dictionary and #Array also introduce quite a bit of visual | > noise... and the JSON sequence is about half as long as the | > literal array sequence and still quite readable... | > | > So, yes I find the JSON format more readable than Igor's suggested | > format. | > | Frankly i do not see any difference between those two. Igor, It depends upon what you are looking for and what is important to you ... I have explained the syntax elements that make JSON more readable for me. Do you acknowledge that the syntax elements {}, [], :, and ,, provide additional syntactic structure that is lacking in the literal array syntax? You may not agree that they are important, but can you at least acknowledge that they might provide useful information that is absent in the pure literal array syntax? If you cannot acknowledge this little bit, then I'm not sure that it is worth discussing any further... | I think, if you ask an outsider who don't knows neither JS nor | Smalltalk syntax (to have unbiased opinion), | i bet he will not be able to easily interpret any of them. Of course .... and my _opinion_ is that the additional syntactic elements in JSON are very useful hints that makes it easier to interpret what you are looking at...when you know what you are looking at. | | Apart of that , is of course, being able to tell the class of object | literal. | Try to express that with JSON: | | #(IdentityDictionary 1 #(#OrderedCollection 1 2 3) 'foo' 'bar' 3 | #(WeakKeyDictionary 1 2 3 #(#Set 1 2 3))) Sven implemented STON (which is actually the format that I prefer ... have you looked at STON?) and has inserted the class names into the format ... STON retains the [], : and {} elements to improve readability. | | maybe you don't need that. But i think there's plenty of others who | may find it very useful. Like I said I prefer STON because it does include class information, you should really take a look:) | | I didn't wanted to turn this discussion into anti-JSON war. So sorry | for that. | (But you know, sometimes it is hard to stop fighting ;) I am shocked that a little bit of JSON on disk has created such waves ... If STON had existed at the time I started I would have used that, although I suspect the same animosity would be directed towards STON, because it is a superset of JSON... | | So, as i already demonstrated, this format, while maybe not best for | humans having clear advantages comparing to have NOTHING at all: | | - you can use it for expressing literals in methods (and even easily | extend compiler to pre-evaluate them at compile time) I don't put STON into literals ... in the smalltalk image, the STON is generated from the objects and written to disk where it may be read/editted by developers using a standard text editor, with emphasis on _may_. | - you can easily extend it to use for many different classes, | without | breaking anything. STON shares this feature... | - and finally, it is fairly small, and simple, because of code reuse | (smalltalk parser) and we're back to where we started from 9 months ago ... GemStone does not have an accessible Smalltalk parser, and the number one requirement for this format is easy portability between dialects (7 smalltalk dialects are involved here...the JSON parser from Seaside with only 27 methods was easily ported to those dialects lacking their own JSON parser ... STON isn't quite as portable, but because of it's additional features will be worth the effort porting)... Dale