<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Implement DOMPoint/DOMPointReadOnly"
href="https://bugs.webkit.org/show_bug.cgi?id=133916#c21">Comment # 21</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Implement DOMPoint/DOMPointReadOnly"
href="https://bugs.webkit.org/show_bug.cgi?id=133916">bug 133916</a>
from <span class="vcard"><a class="email" href="mailto:krit@webkit.org" title="Dirk Schulze <krit@webkit.org>"> <span class="fn">Dirk Schulze</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=133916#c20">comment #20</a>)
<span class="quote">> I talked to Geoff about built-ins. Using built-ins would be advantageous if
> we think most property access on these classes is going to come from script.
> However, if they are mainly used as parameters to call into native code, or
> if used largely from native code, then they would be better as native code.
>
> I don't have a feel for how DOMPoint etc are likely to be used in the wild.
> My guess is that most devs currently just use [x, y] or { x:, y: }, and
> would get little win from using DOMPoint.
>
> DOMRect and DOMRectInit are certainly going to be used as arguments to
> IntersectionObserver, but maybe also stand-alone in script?
>
> DOMMatrix is the one class that is more likely to be used extensively from
> script, so I think it might get the most win from being a built-in.
>
> Of course, we can always change something to being a built-in once we have
> usage experience from the wild.</span >
DOMPoint and DOMRect are for DOM to JS communication. So built-ins might be less useful. I agree for DOMMatrix though. Especially with WebGL and WebVR as future main consumer.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>