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 <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
