Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121177
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-958-g1b1b911df8-fm-20230927.002-g1b1b911d
MIME-Version: 1.0
Message-ID: <5ace1060-dd75-4cdc-b5e2-a2ea617df586@app.fastmail.com>
In-Reply-To: <48c7bb29-a52c-416e-b855-be2746dc7a84@gmail.com>
References: <c7a7f77b-8187-23f7-7c02-c92f1b538039@gmail.com>
 <48c7bb29-a52c-416e-b855-be2746dc7a84@gmail.com>
Date: Fri, 29 Sep 2023 16:58:16 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
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 7:07 AM, Niels Dossche wrote:
> On 02/09/2023 21:41, Niels Dossche wrote:
>> Hello internals
>> 
>> I'm opening the discussion for my RFC "DOM HTML5 parsing and serialization support".
>> https://wiki.php.net/rfc/domdocument_html5_parser
>> 
>> Kind regards
>> Niels
>
> Hi internals
>
> Discussion seems to have died down.
> Today, it's been 14 days since the last major change was done to the 
> RFC (i.e. the class hierarchy update).
> And it's also been close to 4 weeks since I first announced the RFC it 
> on the mailing list.
> I'd like to start the vote on Monday (20:00 PM GMT+2) and I intend to 
> let it run for 2 weeks.
> Any final complaints should be raised now.
>
> Kind regards
> Niels

From the RFC:

> \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?

> Similarly, the constants would lose their DOM_ prefix in the namespace version, e.g. DOM\INDEX_SIZE_ERR will be an alias for DOM_INDEX_SIZE_ERR. For constants that begin with XML_ I propose to keep the prefix. 

Unclear to me: Would the XML constants also be aliased into the namespace verbatim, or left globally?  

Did you consider making the new classes throw exceptions rather than forcing people to remember to call another "was there an error" global function like it's still 1996? :-)

Otherwise looks good to me.  Thanks!

--Larry Garfield