Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121178
Message-ID: <ce503f1d-019b-2def-6c32-c0d84cbf77e4@bastelstu.be>
Date: Fri, 29 Sep 2023 19:13:25 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <c7a7f77b-8187-23f7-7c02-c92f1b538039@gmail.com>
 <48c7bb29-a52c-416e-b855-be2746dc7a84@gmail.com>
 <5ace1060-dd75-4cdc-b5e2-a2ea617df586@app.fastmail.com>
In-Reply-To: <5ace1060-dd75-4cdc-b5e2-a2ea617df586@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and
 serialization support
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

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