BTW, I noticed that the CustomToJS IDL attribute in HTMLCollection.idl is not implemented - instead, there&#39;s just a big hard-coded list of classes in CodeGeneratorJS.pm::UsesManualToJSImplementation() that corresponds to that functionality.<div>
<br></div><div>Any reason not to get rid of UsesManualToJSImplementation() in favor of an explicit CustomToJS attribute? I&#39;m happy to put together a patach for this.</div><div><br></div><div>-atw<br><div><br></div><div>
<br><br><div class="gmail_quote">On Sat, Jul 4, 2009 at 3:02 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jul 4, 2009, at 11:52 AM, Drew Wilson wrote:</div><br><blockquote type="cite"><div><br></div><div>1) I don&#39;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&#39;ve let me do this, but it still defines toJS() in the AbstractWorker.h file. I&#39;d rather have this generate a compile error than have incorrect behavior at runtime.</div>
</blockquote><div><br></div></div><div>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&#39;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.</div>
<div class="im"><br><blockquote type="cite"> <div><br></div><div>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.</div>
</blockquote><div><br></div></div><div>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&#39;t ever want to vend an &quot;Element&quot; wrapper for something that actually should be an &quot;HTMLDivElement&quot;, even if it got returned from a context that deals with generic elements.</div>
<div class="im"><br><blockquote type="cite"> <div><br></div><div><br></div><div>I don&#39;t know how useful the diff would be, but I uploaded one here - it&#39;s not ready for review yet as it has lots of odd debugging flotsam in it: <a href="https://bugs.webkit.org/attachment.cgi?id=32257&amp;action=review" target="_blank">https://bugs.webkit.org/attachment.cgi?id=32257&amp;action=review</a></div>
</blockquote><br></div></div><div>It sounds like you&#39;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.</div>
<div><br></div><div>Regards,</div><div>Maciej</div><font color="#888888"><div><br></div></font></div></blockquote></div><br></div></div>