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 <oli...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
