If you don't need the base 'type' in the binding layer code, you don't have to specify it in the V8Index file. Prototype chains and instanceof operations are all handled by V8 based on the code generated from the IDL files and it is independent of the 'type' declarations in the V8Index file.
Cheers, -- Mads On Tue, Jul 21, 2009 at 6:13 PM, Drew Wilson<atwil...@chromium.org> wrote: > 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 <aba...@chromium.org> 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<jor...@chromium.org> wrote: >> > On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson <atwil...@google.com> >> > 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 <jor...@chromium.org> >> >> 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 <jor...@chromium.org> >> >>> 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 <atwil...@chromium.org> >> >>>> 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 <atwil...@chromium.org> >> >>>>> 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
