Sigh. I keep sending this with the wrong email address. I wish Gmail would just use the address from the last time I replied to the thread. -=-=-
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. -atw 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 -~----------~----~----~----~------~----~------~--~---
