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 -~----------~----~----~----~------~----~------~--~---
