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