<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#c20">Comment # 20</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:simon.fraser@apple.com" title="Simon Fraser (smfr) <simon.fraser@apple.com>"> <span class="fn">Simon Fraser (smfr)</span></a>
</span></b>
<pre>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.</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>