On 19 October 2012 18:36, Alexandre Bergel <alexandre.ber...@me.com> wrote: >> but i agree , this is arguable. As long as you using objects which >> provide own converters, >> (so a generic one never takes place), you don't have to worry about it. > > I think this would be interesting > >>> According to the object you are converting into a string, #storeString may >>> produce code that exceed the amount of literal you can have in a method. >>> Maybe #asObjectLiteral could split the result into chunk that can be >>> individually embedded in a single method. >> >> not the case. >> #( whatever (no matter how deeply nested) ) is a _single_ literal. > > he he, that's cool! > > >>> How large your parser is? >>> >> >> if you asking this quesiton, you miss the point totally. there is no >> parser except smalltalk parser. >> :) > > Ya ya.. I was referring to the amount of code to implement this. > > What about the method #parseAsObjectLiteral? > this one just for using smalltalk parser to parse the input string. nothing complicated (except that our existing parser don't have a good API to do that, that's why this code is a bit messy). But still, that code is just parsing (not evaluating anything)..
> If I understood correctly, the JSON format is rooted in the need to define > classes no? > well, i meant that i don't even need to create any new classes in system to implement that, just couple extension methods here and there. so, it is very lightweight comparing to anything which needs own parser + own classes for that etc. you cannot use dictionaries for representing JS objects because the order of property declaration in them sometimes important, while for smalltalk dictionaries apparently not . > Alexandre > -- Best regards, Igor Stasenko.
