Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121180
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-958-g1b1b911df8-fm-20230927.002-g1b1b911d
MIME-Version: 1.0
Message-ID: <3a80f0a8-c6a1-47d3-bf18-b292037e84f1@app.fastmail.com>
In-Reply-To: <ce503f1d-019b-2def-6c32-c0d84cbf77e4@bastelstu.be>
References: <c7a7f77b-8187-23f7-7c02-c92f1b538039@gmail.com>
 <48c7bb29-a52c-416e-b855-be2746dc7a84@gmail.com>
 <5ace1060-dd75-4cdc-b5e2-a2ea617df586@app.fastmail.com>
 <ce503f1d-019b-2def-6c32-c0d84cbf77e4@bastelstu.be>
Date: Fri, 29 Sep 2023 17:58:22 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and serialization
 support
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Sep 29, 2023, at 5:13 PM, Tim D=C3=BCsterhus wrote:
> Hi
>
> On 9/29/23 18:58, Larry Garfield wrote:
>>> \DOMDocument will also use DOM\Document as a base class to make it i=
nterchangeable with the new classes. We're only adding XMLDocument for c=
ompleteness 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 wi=
th HTMLDocument, and the construction is designed to be more misuse-resi=
stant. \DOMDocument will NOT change, and remains for the foreseeable fut=
ure.
>>=20
>> 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\XMLDocu=
ment 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=20
> bring in the crappy non-static load*() methods that the new API wants =
to=20
> avoid, because their behavior is extremely surprising.
>
> \DOMDocument extends \DOM\XMLDocument would probably work, but would n=
ot=20
> provide an improvement in (backwards) compatibility.
>
> If you want to support everything, update your type declarations to=20
> either \DOM\Document (which is the new abstract base class) or use uni=
on=20
> types.
>
> Please also keep in mind that this is a new API that needs to live for=20
> 10+ years. It makes sense to make it as clean as possible and fully=20
> opt-in, while not unnecessarily breaking compatibility. Any "extends"=20
> hierarchy will likely result in sadness a few years down the road.=20
> Better make a clean cut.

Fair enough, thanks for clarifying.  I guess union types are "good enoug=
h" for this sort of case.

--Larry Garfield