On Sep 22, 10:55 am, Thomas Broyer <[EMAIL PROTECTED]> wrote:
>
> Judging from the "example API usage" from the issue tracker, it seems
> a lot more convenient to use than the current API, and that's really
> good!
Glad to hear it!
>
> One small remark: a 'JSON' is a "specialized" two-item array, so you
> cannot cast it to your own overlay class. It's not a show-stopper, but
> it would be really good if there was a way to parse a JSON string and
> get a JavaScriptObject: you'll get the "sanity check" (that could be
> disabled with an optional boolean argument) and parsing (without
> dealing with eval() yourself) but loose "structure validation", at
> your own risk (but when you have control on the JSON being parsed, you
> don't really need it).
Good point. I could quite easily make an asJavaScriptObject() method
which first digs through whatever path you've setup, then returns the
raw jso from there. (so,
json.get("foo").get("bar").asJavaScriptObject() will return the X in
{foo: {bar: X}}.
>
> (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.
> 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.
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'.
> 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.
Also, that would result in twice the method count: getAsString("key"),
getAsString("key", "default"), getAsString(index), getAsString(index,
"default").
> 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.
Gracias for the feedback, Thomas!
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
