Thanks for the gmail tip, Jeremy - I think my life will be much happier now.
I managed to catch Mads in chat, and he suggested that the pattern to follow
is the one in V8DOMWrapper::converNodeToV8Object(). That code looks at the
type of the impl object passed in, and generates the appropriate wrapper
(DOCUMENT, SVGDOCUMENT, etc) based on that. I suspect that I'll be able to
get rid of WORKERCONTEXT ultimately since it's not directly instantiable
(never have a wrapper of that concrete type).
-atw
On Tue, Jul 21, 2009 at 10:42 AM, Drew Wilson <atwil...@chromium.org> wrote:
> Yes, there's polymorphism in the IDL files. For example, the IDL for
> DedicatedWorkerContext is:
> interface [
> <bunch of random attributes>
> ] DedicatedWorkerContext : WorkerContext {
>
> void postMessage(in DOMString message, in [Optional] MessagePort
> messagePort)
> raises(DOMException);
> attribute EventListener onmessage;
>
> };
>
> The JSC bindings reflect this nicely, because there's a class hierarchy in
> JSC that matches the hierarchy in the IDL files.
>
> -atw
>
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
