[webkit-dev] Internal JSON Parsing

Jarred Nicholls jarred at webkit.org
Thu Dec 8 09:19:43 PST 2011


That's precisely what I wanted to do initially.  I had conflicting feelings
on this, but my first intuition was to cache in the bindings the value
directly parsed and state managed by the respective VM.  I don't see this
value being used by a different binding layer in parallel.

On Thu, Dec 8, 2011 at 12:08 PM, Oliver Hunt <oliver at apple.com> wrote:

> It's not safe to use ScriptObject for values that are kept alive by JS
> objects as it leads to cycles in the collector.
>
> Also the cached value for an attribute should be in the binding classes,
> not the implementation classes.  The easiest way to understand why is to
> ask yourself how a non-js (objc, gobject, etc) binding layer would use the
> same cached value.
>
> I suspect you can probably just kill off the no custom
> getter+CachedAttribute check in the code generator as I think i was simply
> being conservative when i wrote that code.
>
> --Oliver
>
> On Dec 8, 2011, at 8:39 AM, Jarred Nicholls wrote:
>
> Hey webkittens,
>
> I'm working on https://bugs.webkit.org/show_bug.cgi?id=73648 to support
> the json response entity from XHR.response.  Unless I'm mistaken (the
> purpose of this inquiry) we don't appear to have a VM-agnostic interface
> for internal JSON parsing, i.e., straight to the parsers.  If so, what does
> everyone think about adding in that basic interface?  What I'd like to
> avoid is preprocessor branches directly in XHR talking to JSC and V8
> directly; instead, what would be ideal I think is an interface to parse and
> return a ScriptObject.
>
> Any additional input is surely welcomed.
>
> Thanks,
> Jarred
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111208/1bcd6030/attachment.html>


More information about the webkit-dev mailing list