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
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/122048Kind 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
Hi Gina
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
Hi Gina
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
Hi internals
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/122048Kind regards
Niels
I'm currently quite busy implementing the last part of the proposal: fixing the type issues.
I'm just letting you know that, based on the current development, I decided to drop the adopt{Legacy,Modern}Node methods from the proposal.
The import{Legacy,Modern}Node methods will remain however.
The reason for the drop is that the adopt method could create two different representations (i.e. DOM\Node and DOMNode) of the same internal object, causing potential issues as the new DOM and old DOM make different assumptions. Importing does not suffer from this because unlike adopting, no copy is made.
Cheers
Niels
Hi internals
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/122048Kind regards
Niels
I basically finished the implementation of the proposal.
The only thing remaining is adding more tests, and fixing bugs if any come up.
All WPT tests that I ported over (in a separate repo) pass as well.
I dropped the importModernNode method from the proposal. Upon trying to implement this, I found that it was too difficult to make it work correctly due to limitations in the import code implementation. In particular, in old DOM, namespaces must always be attached to an element. But when importing a node with namespaced attributes, this could sometimes lose the namespace of those attributes because at that point the cloned subtree is not attached to the document yet. While it's probably possible to fix this for most cases, there will always be cases where this causes issues. As such, I rather not provide this functionality than provide it in a half-working/half-broken state. The reverse direction, importLegacyNode, does not suffer from this problem because we have our own namespace handling code for new DOM.
TL;DR: importModernNode is gone, importLegacyNode remains.
There has also been no discussion for quite some time now.
So if nothing changes, I'd like to put it to vote on Tuesday 13-02.
Kind regards
Niels