[Webkit-unassigned] [Bug 102240] [V8] Rename dispatchWrap

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=102240





--- Comment #6 from Dan Carney <dcarney at google.com>  2012-11-27 00:43:16 PST ---
(In reply to comment #5)
> Forgive me, it looks like I am behind your wrap/createWrapper/toV8/toV8Fast work...
> 
> (1) What is [V8NoWrapperCache] for ? I am expecting that [CustomToJSObject] and [V8CustomToJSObject] would be sufficient.
> 
> (2) Why do you need to let developers write both custom toV8() and custom wrap() ? Previously we supported custom toV8() only and didn't support custom wrap(). Why do you now need to support both custom toV8() and custom wrap() ?

I moved the functionality around.  wrap used to first check the wrapper cache then built the wrapped object. toV8 checked the wrapper, then called wrap, which often checked the cache a number of times. I ensured now that the check is only performed once, in toV8 (or toV8fast, or toV8Object), and then the call is passed to wrap. No wrap call should be made outside of the bindings.

A V8NoWrapperCache means that there will never be a cache used for such object, so wrap is not generated, and in that case, we must have a custom v8 implementation since we have no idea what the intention is such a call.

Sometimes a wrap implementation  might want to use the wrapper cache though, and just do some type checking and dispatch the wrap call down the subclass chain. That's marked as V8CustomToJSObject or CustomToJSObject.

By splitting functionality I ensured that the wrapper cache check is pretty much always autogenerated and performed just once. Additionally, it meant that toV8 and toV8Fast can almost always be generated, which wasn't previously the case for classes marked (V8)CustomToJSObject

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.