Re: [PHP-DEV] [RFC] [Discussion] Opt-in DOM spec-compliance

2024-01-19 Thread Gina P. Banyard
On Thursday, 18 January 2024 at 20:08, Niels Dossche  
wrote:
> 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.

Understandable, I suppose we can always deprecate the import modern node 
methods before the import legacy nodes.

> > 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.

ACK

Best regards,

Gina P. Banyard

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] [Discussion] Opt-in DOM spec-compliance

2024-01-18 Thread Niels Dossche
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



Re: [PHP-DEV] [RFC] [Discussion] Opt-in DOM spec-compliance

2024-01-18 Thread Gina P. Banyard
On Wednesday, 17 January 2024 at 20:22, Niels Dossche  
wrote:
> Hi internals
> 
> I'm starting discussion of my RFC "Opt-in DOM spec-compliance".
> 
> RFC link: https://wiki.php.net/rfc/opt_in_dom_spec_compliance
> Pre-RFC pitch: https://externals.io/message/122048
> 
> Kind regards
> Niels

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.
The other thing to clarify is why and when would those return false, compared 
to the methods that import legacy nodes which never throw?

Best regards,

Gina P. Banyard

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php