On Tue, Jul 21, 2009 at 10:27 AM, Drew Wilson <atwil...@chromium.org> wrote:
> 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. Settings -> Accounts -> When receiving a message:Reply from the same address the message was sent to > > -=-=- > > 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 <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 -~----------~----~----~----~------~----~------~--~---
