Hi,
On 21 sep, 08:11, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
> It was a lot more work than I originally thought, but its done, and it
> does include the ability to create JSON and not just read it.
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!
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).
(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!)
> NB3: I didn't test speed, but this version should be similarly fast.
> The main speed boost of the old library: Lazy java-ification of the
> values, is preserved in the new API. The new API re-walks the tree on
> every lookup whereas the old one doesn't,
I haven't read all the threads about this new API, could you enlighten
me about this implementation design choice?
Why couldn't a JSON instance represent the actual value (or a wrapper
in the case of primitive values)? (and you'd use a toJSON method
rather than an overridden toString)
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)?
(sorry if it has already been discussed; point me to the message/
thread if this is the case)
> The parsing bit is slower, but that's because of the safety
> measures.
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)
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
