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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
