Re: Pre-RFC: Fixing spec bugs in the DOM extension

From: 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

« previous php.internals (#122065) next »