On 22 sep, 17:17, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > On Sep 22, 10:55 am, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > > (also, if 'JSON' wasn't an overlay, with its two parts stored in local > > variables (and without the "monkey patching" of toString), what would > > be the impact on generated-code size and performance? JSON being a > > JSO, it's tempting to cast it to some other JSO, while its internals > > should IMO stay... internal!) > > Given the 1.5k savings between this API and the old one, I'd hazard a > guess that its somewhat significant. I'm a bit busy at the moment, but > I'll add a todolist item to see what happens if I make this non-JSON > and just use a String[] for path and a JavaScriptObject instead of an > internal 2-item array to store these things. Very much agreed that, if > the difference isn't significant, that would be better design.
You could replace String[] with JsArrayString eventually (see also issue 2793). http://code.google.com/p/google-web-toolkit/issues/detail?id=2793 > > I haven't read all the threads about this new API, could you enlighten > > me about this implementation design choice? > > Two reasons: Error messages, which is the bonus, but mostly: > > So that setting variables is properly supported. Let's say I dropped > the 'path' part of the internal representation entirely, then if I > did: > > JSON json = JSON.parse(whatever); > JSON userInfo = json.get("user_info"); > userInfo.get("age").setInt(10); > > it just couldn't work; after all, userInfo is merely a JSO > representing [undefined] - there's no way to retroactively add a > user_info key to the top-level json map. OK, though the following would be more explicit: JSON json = JSON.parse(whatever); JSON userInfo = json.getObject("user_info", true /* create if missing */); userInfo.set("age", 10); // "int" could be an overload, or use setInt if you prefer This would work similarly to this Python code: json = JSON.parse(whatever) userInfo = json.setDefault("user_info", {}) # Notice: setDefault(), not get() with a default/fallback value userInfo.age = 10 > The second problem: It'd have to be an array with undefined in it, > because undefined is not itself a valid JSO; it seems to work in web > mode, but the hosted mode bridge will throw exceptions. Either way its > not quite as simple as 'you just get your JSON device as a JavaScript- > side item, with useful methods added to it via overlay'. Sorry, don't understand... > > Following the same idea, how about getAsString("name") rather than > > get("name").asString(), and using overlays for "lists" and > > "maps" ("list" being a specialized "map", just as a javascript Array > > is a specialized Object)? > > I couldn't make the concept work with that scheme: When setting > values, you'd be forced to manually build up the structure instead of > having it auto-generated for you. I'm for explicit behaviors (see example code above) > Also, that would result in twice the method count: getAsString("key"), > getAsString("key", "default"), getAsString(index), getAsString(index, > "default"). I don't see this as a problem. > > As I said above, having a way to disable it (JSON.parse(jsonString, > > false) and/or deferred binding) would be a useful addition (for > > instance, in Adobe AIR, eval() only parses JSON-like constructs after > > the 'onload' event) > > I could add a parseUnsafe, and that was the plan, but previous > discussion (see links to other discussions in the Issue Tracker) > suggested that it would be easier for everybody involved if there was > ONLY safe parsing, and that it would be acceptable if safe parsing > isn't significantly slower. I admit I haven't benchmarked parse yet. Yes, of course, if sanity checks don't cost "that much", it's OK to have them run in all cases. Let me try another API if I find time ;-) --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
