Re: Pre-RFC: Fixing spec bugs in the DOM extension
| From: | Niels Dossche | Date: | Fri, 29 Dec 2023 23:41:22 +0000 |
| Subject: | Re: Pre-RFC: Fixing spec bugs in the DOM extension | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-122065@lists.php.net to get a copy of this message | ||
Hi Larry
On 29/12/2023 17:58, Larry Garfield wrote:
>
> I am also on team "yes, let's just do it right." If that means the new classes
> are only 99% drop ins for the old ones, I'm OK with that. People can switch over when
> they're ready and do all the clean up at once.
>
They are indeed going to be very similar, but at least having better return types would be good to
give one particular example.
e.g. we currently have a lot of methods that can return an object or false. The current living DOM
spec always throws exceptions instead of returning false on error which is a much cleaner API.
Furthermore, we have the DOMNameSpaceNode that can be returned by some methods and has been a point
of confusion for static analysis tools (I did a PR on psalm to fix one of those issues).
That node type won't be special cased in the new classes API so the (inconsistent use of the)
union of DOMAttr|DOMNameSpaceNode will go away.
> I'm not sure about making things final. I don't know the domain space well enough to
> have a strong opinion at the moment, but my main concern would be ensuring that it's still
> extensible in reasonable ways. Eg, if I wanted to add a Web Component element to a page, I want to
> do that without fugly workarounds. I don't have a strong opinion at this point on what the
> right way to do that is.
>
Yeah indeed.
> --Larry Garfield
>
Kind regards
Niels