The other unanswered question is whether it's useful to define the base "type" in V8Index.h. If a wrapper of the base type (WRAPPERCONTEXT) is never instantiated, do I still need to define it for the purposes of things like "instanceof" and prototype chains? Or is it *only* used to specify the type of wrapper instances?
-atw On Tue, Jul 21, 2009 at 10:58 AM, Adam Barth <[email protected]> wrote: > I think the way this works in general is that you create the wrapper > for the derived class. You can see all the switch statements in > V8DOMWrapper.cpp that try to do this for Nodes, etc. > > Adam > > > On Tue, Jul 21, 2009 at 10:32 AM, Jeremy Orlow<[email protected]> wrote: > > On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson <[email protected]> > wrote: > >> > >> It seems like that would have some undesirable side-effects, aside from > >> the fact that WebKit frowns on using virtual functions unnecessarily. > >> So, let's imagine that I have two derived classes, SharedWorkerContext > and > >> DedicatedWorkerContext. DedicatedWorkerContext wants to expose > postMessage() > >> as a public callable function, but SharedWorkerContext would not. > >> If we only have a single V8 "class" for both of these (WORKERCONTEXT) > then > >> that implies: > >> 1) I have to define postMessage() as a virtual function on the base > >> WebCore class (WorkerContext). In fact, WorkerContext ends up containing > the > >> union of all exposed APIs for every future derived class, which seems > ugly. > >> 2) From javascript, if I have a SharedWorkerContext, and I do this > "typeof > >> postMessage", it should return "undefined" (since SharedWorkerContext > does > >> not define this attribute) - however, since SharedWorkerContext is > actually > >> just a vanilla WORKERCONTEXT behind the scenes, it would return > "function", > >> which violates the spec. > >> It seems like the right way to do this is to actually have separate V8 > >> items. The alternative is to have just a single WORKERCONTEXT, but > instead > >> of using polymorphism have custom getters/setters for every attribute > that > >> check the type of the impl class and do the appropriate thing. But it > seems > >> like the whole point of having the V8ClassIndex enum is to avoid this > kind > >> of manual polymorphism. > > > > Good points. > > Are there other use cases for building polymorphism into V8? Is there > any > > notion of polymorphism in the IDL files? Maybe the best answer is to > just > > make them two completely different classes. It kind of seems like doing > > this elegantly is going to cost us performance wise one way or another. > > J > > > >> On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow <[email protected]> > wrote: > >>> > >>> In other words, make all workers appear the same to V8 (i.e. as a > >>> WORKERCONTEXT) and then implement polymorphism in the implementations > being > >>> wrapped by V8. > >>> On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow <[email protected]> > >>> wrote: > >>>> > >>>> Sorry if this is a dumb question, but why woudn't you simply have a > >>>> WORKERCONTEXT and let virtual dispatch do its job for the rest? > Shared > >>>> methods can be implemented on the base class and the rest can be > purely > >>>> virtual with implementations in the sub classes. > >>>> J > >>>> > >>>> On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson <[email protected]> > >>>> wrote: > >>>>> > >>>>> Following up on this. Let's imagine that I don't define a > V8ClassIndex > >>>>> enum for the common base class (so, in my case, I get rid of > WORKERCONTEXT, > >>>>> and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the > derived > >>>>> classes). > >>>>> Now, let's say I'm defining an ACCESSOR_GETTER on the base class - > the > >>>>> first thing I want to do is get a pointer to the native object. I > don't know > >>>>> which concrete class the native object is (DedicatedWorkerContext or > >>>>> SharedWorkerContext), but I do know that it's guaranteed to be an > instance > >>>>> of the base native class (WorkerContext). > >>>>> Currently I'm doing this: > >>>>> WorkerContext* workerContext = > >>>>> > V8DOMWrapper::convertToNativeObject<WorkerContext>(V8ClassIndex::WORKERCONTEXT, > >>>>> info.Holder()); > >>>>> If I remove V8ClassIndex::WORKERCONTEXT, then I can't pass that in to > >>>>> convertToNativeObject. It looks like the passed-in enum is only used > for > >>>>> error checking currently, so I guess what I should use instead is > >>>>> convertDOMWrapperToNative()?: > >>>>> WorkerContext* workerContext = > >>>>> > V8DOMWrapper::convertDOMWrapperToNative<WorkerContext>(info.Holder()); > >>>>> Is that the general pattern people use for cases like this? > >>>>> -atw > >>>>> On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson <[email protected]> > >>>>> wrote: > >>>>>> > >>>>>> <resending from correct acct>: > >>>>>> Currently, Web Workers have a class (WorkerContext) which represents > >>>>>> the global scope for a worker. The custom V8 bindings for this class > are > >>>>>> defined in V8WorkerContextCustom, and we also define > >>>>>> V8ClassIndex::WORKERCONTEXT for the wrapper object. > >>>>>> I'm refactoring the WebCore impl class, so WorkerContext becomes > >>>>>> (essentially) an abstract base class, and the actual worker context > will be > >>>>>> one of two derived classes: DedicatedWorkerContext or > SharedWorkerContext. > >>>>>> In my refactoring, I've only implemented a single derived class > >>>>>> (DedicatedWorkerContext) for now. > >>>>>> I'm trying to figure out the correct way to structure the V8 > bindings > >>>>>> - I've already made a pass at it that passes all of the unit tests: > >>>>>> https://bugs.webkit.org/show_bug.cgi?id=27420 > >>>>>> I've defined V8ClassIndex::DEDICATEDWORKERCONTEXT, but I'm not > certain > >>>>>> if I need to remove V8ClassIndex::WORKERCONTEXT or not, since there > >>>>>> shouldn't ever be a wrapper object created for that base class. Are > the > >>>>>> wrapper types defined in V8Index.h only for actually instantiable > wrapper > >>>>>> objects (in which case I should only define them for the "leaves" of > the > >>>>>> tree), or is it used for other things like instanceof? > >>>>>> -atw > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
