[webkit-dev] Inheritance in IDL files/JS bindings

[Drew Wilson]

Thanks for the insights.
I stepped through the worker constructor code. The problem was at the very
last line, where we create a JS wrapper object around the core
WebCore::Worker object:

    return asObject(toJS(exec, worker.release()));

Before I changed Worker.idl to have Worker derive from the AbstractWorker
interface, the generator was creating a toJS() function in JSWorker. Once I
changed Worker to derive from AbstractWorker, the generator stopped putting
toJS() in JSWorker, so the code was falling through to call the base-class
code and returning an AbstractWorker object. I guess by default the
generator only creates toJS() functions for base classes?

In this case, adding GenerateToJS to Worker.idl fixed the problem by telling
the generator to create a toJS() function for JSWorker as well. Is that the
right fix?

I still have a couple of questions:

1) I don't ever actually want a raw JSAbstractWorker to be created - is
there a way to disable the toJS() generation? It looks like maybe CustomToJS
might've let me do this, but it still defines toJS() in the AbstractWorker.h
file. I'd rather have this generate a compile error than have incorrect
behavior at runtime.

2) What does GenerateNativeConverter do? I note that both Node and
Element.idl define GenerateToJS, but none of their derived classes
(HTMLElement.idl, HTMLOptionElement.idl) define GenerateToJS, which makes me
think that just defining GenerateToJS on derived classes is not the correct
fix.


I don't know how useful the diff would be, but I uploaded one here - it's
not ready for review yet as it has lots of odd debugging flotsam in it:
https://bugs.webkit.org/attachment.cgi?id=32257&action=review

-atw


On Fri, Jul 3, 2009 at 3:23 PM, Sam Weinig <sam.weinig at gmail.com> wrote:

>
>
> On Fri, Jul 3, 2009 at 2:42 PM, Drew Wilson <atwilson at google.com> wrote:
>
>> I'm working on refactoring some code out of WebCore::Worker into a common
>> base class to be shared between SharedWorker and Worker.
>> So I've defined a new AbstractWorker.idl and its associated JS bindings.
>> AbstractWorker is not intended to be instantiable, so I don't have a
>> constructor generated for it.
>>
>>     interface [CustomMarkFunction, Conditional=WORKERS] AbstractWorker {
>>         ...
>>     }
>>
>
> GenerateConstructor is a slight misnomer unfortunately.  Event
> non-instatiatable interfaces should have one so that they can be exposed on
> the global object for use with instanceof and accessing the prototype.
>
>
>>
>> I then changed Worker.idl to make the Worker interface derive from the
>> base AbstractWorker interface, like so:
>>
>>     interface [CustomMarkFunction, Conditional=WORKERS] Worker :
>> AbstractWorker {
>>                ...
>>     }
>>
>> Everything compiles just fine, except that at runtime when I instantiate a
>> Worker object from Javascript, I seem to get an instance of AbstractWorker
>> instead, and referencing things that should be defined on the Worker
>> prototype (like Worker::postMessage) yields undefined. I thought at first
>> that perhaps I was doing something wrong with the prototype (setup in
>> JSWorkerConstructor.cpp) so I wrote some JS tests, which produced the
>> expected results:
>>
>>     log(Worker.toString());   => "[object WorkerConstructor]"
>>     log(Worker.prototype.toString());    => "[object WorkerPrototype]"
>>     log(Worker.prototype.postMessage.toString());   => "function
>> postMessage() { [native code] }"
>>
>> And yet when I actually instantiate a Worker object:
>>
>>     var worker = new Worker("resources/worker-common.js");
>>     log (worker.toString());    => "[object *AbstractWorker*]"
>>     log (typeof worker.postMessage);    => "*undefined*"
>>
>> Is there anything special I need to do when implementing inheritance in
>> IDL files and JS bindings? I *think* I'm correctly following the example of
>> other places where we use inheritance (example HTMLElement -> Element ->
>> Node), although there are some options defined in the .idl file like
>> "GenerateNativeConverter" and "GenerateToJS" that might be relevant but
>> which I couldn't find any documentation for.
>>
>> Anyhow, I'm digging into this further, but I figured people might be able
>> to shed some light on possible causes of this behavior.
>>
>
> It is hard to say without a full diff.  Nothing you have described seems
> too far off.
>
> -Sam
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090704/bc37b32c/attachment.html>