Re: Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

Hi On 9/29/23 18:58, Larry Garfield wrote:

\DOMDocument will also use DOM\Document as a base class to make it interchangeable with the new classes. We're only adding XMLDocument for completeness and API parity. It's a drop-in replacement for \DOMDocument, and behaves the exact same. The difference is that the API is on par with HTMLDocument, and the construction is designed to be more misuse-resistant. \DOMDocument will NOT change, and remains for the foreseeable future.

Would it make sense then for one of \DOMDocument and DOM\XMLDocument to extend the other, then? So that, eg, we can type against DOM\XMLDocument and then support both old and new classes? Or are the construction et al differences enough that is not viable?

As one of the persons who convinced Niels of this new API design: \DOM\XMLDocument extends \DOMDocument doesn't work, because it would bring in the crappy non-static load*() methods that the new API wants to avoid, because their behavior is extremely surprising. \DOMDocument extends \DOM\XMLDocument would probably work, but would not provide an improvement in (backwards) compatibility. If you want to support everything, update your type declarations to either \DOM\Document (which is the new abstract base class) or use union types. Please also keep in mind that this is a new API that needs to live for 10+ years. It makes sense to make it as clean as possible and fully opt-in, while not unnecessarily breaking compatibility. Any "extends" hierarchy will likely result in sadness a few years down the road. Better make a clean cut. Best regards Tim Düsterhus