wikimedia/mediawiki-extensions-DiscussionTools
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/DiscussionTools synced 2024-09-29 05:16:27 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-Discus.../.phan/stubs/DomImpl.php

22 lines
1.4 KiB
PHP
Raw Normal View History

Use DOMCompat::newDocument() to create a new Document For compatibility with Parsoid's document abstraction (Parsoid may switch to an alternate DOM library in the future), don't explicitly create a new document object using `new DOMDocument`; instead use the Parsoid wrapper `DOMCompat::newDocument()`. This ensures that the Document object created will be compatible with Parsoid. There are a number of other subtle dependencies on the PHP `dom` extension in DiscussionTools, like explicit `instanceof` tests; those will be tweaked in a follow-up patch (I3c4f41c3819770f85d68157c9f690d650b7266a3) since they do not affect correctness so long as Parsoid is aliasing Document to a subclass of the built-in DOMDocument. Similarly, the Phan warnings we suppress do not cause runtime errors (because of the fixes included in c5265341afd9efde6b54ba56dc009aab88eff83c) but phan will be happier once the follow-up patch lands and aligns all the DOM types. Bug: T287611 Depends-On: If0671255779571a91d3472a9d90d0f2d69dd1f7d Change-Id: Ib98bd5b76de7a0d32a29840d1ce04379c72ef486
2021-07-29 02:13:09 +00:00
<?php
Don't refer directly to PHP `dom` extension classes; avoid nonstandard behavior These changes ensure that DiscussionTools is independent of DOM library choice, and will not break if/when Parsoid switches to an alternate (more standards-compliant) DOM library. We run `phan` against the Dodo standards-compliant DOM library, so this ends up flagging uses of non-standard PHP extensions to the DOM. These will be suppressed for now with a "Nonstandard DOM" comment that can be grepped for, since they will eventually will need to be rewritten or worked around. Most frequent issues: * Node::nodeValue and Node::textContent and Element::getAttribute() can return null in a spec-compliant implementation. Add `?? ''` to make spec-compliant results consistent w/ what PHP returns. * DOMXPath doesn't accept anything except DOMDocument. These uses should be replaced with DOMCompat::querySelectorAll() or similar (which end up using DOMXPath under the covers for DOMDocument any way, but are implemented more efficiently in a spec-compliant implementation). * A couple of times we have code like: `while ($node->firstChild!==null) { $node = $node->firstChild; }` and phan's analysis isn't strong enough to determine that $node is still non-null after the while. This same issue should appear with DOMDocument but phan doesn't complain for some reason. One apparently legit issue: * Node::insertBefore() is once called in a funny way which leans on the fact that the second option is optional in PHP. This seems to be a workaround for an ancient PHP bug, and can probably be safely removed. Bug: T287611 Bug: T217867 Change-Id: I3c4f41c3819770f85d68157c9f690d650b7266a3
2021-07-29 02:16:15 +00:00
# For the purpose of phan, we're always using IDLeDOM. That avoids the
# type variance/co-variance issues involved in teaching phan about our
# subclasses, and also keeps us from accessing any private implementation
# details of Dodo.
#
# This list should match the one in DomImpl.php in the root.
Use DOMCompat::newDocument() to create a new Document For compatibility with Parsoid's document abstraction (Parsoid may switch to an alternate DOM library in the future), don't explicitly create a new document object using `new DOMDocument`; instead use the Parsoid wrapper `DOMCompat::newDocument()`. This ensures that the Document object created will be compatible with Parsoid. There are a number of other subtle dependencies on the PHP `dom` extension in DiscussionTools, like explicit `instanceof` tests; those will be tweaked in a follow-up patch (I3c4f41c3819770f85d68157c9f690d650b7266a3) since they do not affect correctness so long as Parsoid is aliasing Document to a subclass of the built-in DOMDocument. Similarly, the Phan warnings we suppress do not cause runtime errors (because of the fixes included in c5265341afd9efde6b54ba56dc009aab88eff83c) but phan will be happier once the follow-up patch lands and aligns all the DOM types. Bug: T287611 Depends-On: If0671255779571a91d3472a9d90d0f2d69dd1f7d Change-Id: Ib98bd5b76de7a0d32a29840d1ce04379c72ef486
2021-07-29 02:13:09 +00:00
Don't refer directly to PHP `dom` extension classes; avoid nonstandard behavior These changes ensure that DiscussionTools is independent of DOM library choice, and will not break if/when Parsoid switches to an alternate (more standards-compliant) DOM library. We run `phan` against the Dodo standards-compliant DOM library, so this ends up flagging uses of non-standard PHP extensions to the DOM. These will be suppressed for now with a "Nonstandard DOM" comment that can be grepped for, since they will eventually will need to be rewritten or worked around. Most frequent issues: * Node::nodeValue and Node::textContent and Element::getAttribute() can return null in a spec-compliant implementation. Add `?? ''` to make spec-compliant results consistent w/ what PHP returns. * DOMXPath doesn't accept anything except DOMDocument. These uses should be replaced with DOMCompat::querySelectorAll() or similar (which end up using DOMXPath under the covers for DOMDocument any way, but are implemented more efficiently in a spec-compliant implementation). * A couple of times we have code like: `while ($node->firstChild!==null) { $node = $node->firstChild; }` and phan's analysis isn't strong enough to determine that $node is still non-null after the while. This same issue should appear with DOMDocument but phan doesn't complain for some reason. One apparently legit issue: * Node::insertBefore() is once called in a funny way which leans on the fact that the second option is optional in PHP. This seems to be a workaround for an ancient PHP bug, and can probably be safely removed. Bug: T287611 Bug: T217867 Change-Id: I3c4f41c3819770f85d68157c9f690d650b7266a3
2021-07-29 02:16:15 +00:00
class_alias( "Wikimedia\\IDLeDOM\\Attr", "Wikimedia\\Parsoid\\DOM\\Attr" );
class_alias( "Wikimedia\\IDLeDOM\\CharacterData", "Wikimedia\\Parsoid\\DOM\\CharacterData" );
class_alias( "Wikimedia\\IDLeDOM\\Comment", "Wikimedia\\Parsoid\\DOM\\Comment" );
class_alias( "Wikimedia\\IDLeDOM\\Document", "Wikimedia\\Parsoid\\DOM\\Document" );
class_alias( "Wikimedia\\IDLeDOM\\DocumentFragment", "Wikimedia\\Parsoid\\DOM\\DocumentFragment" );
class_alias( "Wikimedia\\IDLeDOM\\DocumentType", "Wikimedia\\Parsoid\\DOM\\DocumentType" );
class_alias( "Wikimedia\\IDLeDOM\\DOMException", "Wikimedia\\Parsoid\\DOM\\DOMException" );
class_alias( "Wikimedia\\IDLeDOM\\DOMParser", "Wikimedia\\Parsoid\\DOM\\DOMParser" );
class_alias( "Wikimedia\\IDLeDOM\\Element", "Wikimedia\\Parsoid\\DOM\\Element" );
class_alias( "Wikimedia\\IDLeDOM\\Node", "Wikimedia\\Parsoid\\DOM\\Node" );
class_alias( "Wikimedia\\IDLeDOM\\NodeList", "Wikimedia\\Parsoid\\DOM\\NodeList" );
class_alias( "Wikimedia\\IDLeDOM\\ProcessingInstruction", "Wikimedia\\Parsoid\\DOM\\ProcessingInstruction" );
class_alias( "Wikimedia\\IDLeDOM\\Text", "Wikimedia\\Parsoid\\DOM\\Text" );
Reference in a new issue Copy permalink