<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/7/21 7:52 PM, Gabriel Ivăncescu
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c8536322-36a9-b3f8-8f07-6372fda4a761@gmail.com">
<blockquote type="cite" style="color: #007cff;">That just doesn't
make sense at all. Once we support prototypes
document.body.setAttribute ===
document.createElement("div").setAttribute ===
document.head.__proto__.setAttribute === Element.setAttribute.
It's one and the same function object, not separated quirk
holders. Hooks are an implementation details of such abstract
functions in context of a specific object type and there is
nothing special about that. They are not a part of function
object itself.
<br>
<br>
</blockquote>
<br>
I did mention the prototype means it is the same function object,
I was using a hypothetical example with quirks. My point was that
<b class="moz-txt-star"><span class="moz-txt-tag">*</span>if<span
class="moz-txt-tag">*</span></b> they end up being different
functions (for any reason), using func_info_t is more correct
because it represents two different functions, with possibly two
different hooks.
<br>
<br>
Don't get me wrong, I did not find yet a case where such a quirk
exists, that's why I mentioned it's hypothetical. Although I did
find some duplicated props in some places. Anyway I think it's
more technically correct, and can be easier handled in the future
<b class="moz-txt-star"><span class="moz-txt-tag">*</span>if<span
class="moz-txt-tag">*</span></b> we find such quirks.<br>
</blockquote>
<p><br>
</p>
<p>No, it's not correct. body element hooks from your example are
free to cast 'this' object to HTMLBodyElement. If it did that,
you'd end up casting div element object to HTMLBodyElement and
likely crash.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:c8536322-36a9-b3f8-8f07-6372fda4a761@gmail.com">
<blockquote type="cite" style="color: #007cff;">
<br>
That all said, I'm not attached to representing those as
DISPIDs. It just feels safe to continue using them here, but
it's possible that something separated will be better at some
point. Your current solution just exposes some MSHTML internals
for no real need.
<br>
<br>
</blockquote>
<br>
Well, they're opaque, so not exposed at all. It's pretty common to
pass "context" or "user" pointers around in callbacks (which is
what this is). Do you think renaming it to "context" is better
then? jscript won't really care what it is, just has to pass it
back to the callback.
</blockquote>
<p><br>
</p>
<p>I think that it needs to fit the rest of the design, so I would
need to see more of it to answer properly. It's not really
something I expected. I imagined that the interface exposed by
MSHTML object could look like this:</p>
<p><br>
</p>
<p>interface IJSDispatchHost</p>
<p>{</p>
<p> HRESULT getJSDispatch(IJSDispatch **p); <br>
</p>
<p> HRESULT setJSDispatch(IJSDispatch *jsdisp); // or maybe
expose a constructor from the script engine itself and call it
from MSHTML instead<br>
</p>
<p> HRESULT getOwnProperty( ... );</p>
<p> HRESULT call(DISPID dispid, unsigned int argc, VARIANT *argv,
VARIANT *r);</p>
<p> // probably more<br>
</p>
<p>}</p>
<p><br>
</p>
<p>On top of that, you'd need a constructor for such wrapped
objects, so another interface exposed by script engine itself will
likely be needed. I don't see why you need anything else.<br>
</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Jacek<br>
</p>
</body>
</html>