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

[Drew Wilson]

BTW, I noticed that the CustomToJS IDL attribute in HTMLCollection.idl is
not implemented - instead, there's just a big hard-coded list of classes in
CodeGeneratorJS.pm::UsesManualToJSImplementation() that corresponds to that
functionality.
Any reason not to
get rid of UsesManualToJSImplementation() in favor of an explicit
CustomToJS attribute? I'm happy to put together a patach for this.

-atw



On Sat, Jul 4, 2009 at 3:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jul 4, 2009, at 11:52 AM, Drew Wilson wrote:
>
>
> 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.
>
>
> I think the right way to handle this is to make a custom toJS function that
> does a runtime check of the actual type, and makes the right kind of wrapper
> object. That's because any time you deal with an AbstractWorker pointer, you
> want toJS on it to return the canonical wrapper of the right concrete class.
> The toJS function for Node is a fairly elaborate example of this.
>
>
> 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.
>
>
> Correct - see above. toJS needs to do a dynamic check based on the runtime
> type, not a static check based on the declared type. We don't ever want to
> vend an "Element" wrapper for something that actually should be an
> "HTMLDivElement", even if it got returned from a context that deals with
> generic elements.
>
>
>
> 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
>
>
>
> It sounds like you're on the right track to figuring this out. I believe writing a custom toJS for AbstractWorker which checks what kind of object it actually has will fix your problem.
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090706/4d47fe18/attachment.html>