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

On Fri, Sep 29, 2023, at 5:13 PM, Tim Düsterhus wrote: > 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. Fair enough, thanks for clarifying. I guess union types are "good enough" for this sort of case. --Larry Garfield