Hi Gina
On 18/01/2024 14:05, Gina P. Banyard wrote:
> Hello Niels,
>
> Thank you for the RFC and the thorough overview of the current state.
>
> I think converting the new aliases to proper classes which have the correct
> spec behaviour is indeed the way to proceed.
>
> I do have some questions however, do you really think we need the DOMDocument
> methods to import modern nodes into legacy documents?
> As I can imagine, this would provide fewer incentives for users to move to
> the new spec compliant classes.
It's a double-edged sword: if we don't provide it, it becomes harder to migrate
and it may take a longer time to do so.
If we do provide it there may be fewer incentives.
I think it's necessary as a first step to aid migration, otherwise, if we don't
provide this, it's going to become more difficult for library maintainers as
they'd have to effectively create two versions of their library in some cases.
By creating these methods it may become possible to use libraries that are not
yet adapted to the new classes. So depending on your point of view it may even
accelerate adoption.
One caveat is, as always, that any migration can be hindered if a library you
try to use relies on bugs that are fixed in the new classes.
> The other thing to clarify is why and when would those return false, compared
> to the methods that import legacy nodes which never throw?
{import,adopt}ModernNode may return false or throw, depending on the
$strictErrorChecking property of DOMDocument, when an error occurs.
The only possible error case really is when an unsupported node is
imported/adopted (e.g. a document itself).
The reason we don't have the false return value for {import,adopt}LegacyNode is
because the DOM\{XML,HTML}Document class doesn't have a $strictErrorChecking
property, i.e. it always uses exceptions.
>
> Best regards,
>
> Gina P. Banyard
Kind regards
Niels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
