f856992ad9
Parsoid abstracts the specific DOM implementation it is using, in
practice (currently) using subclasses of the built-in \DOMDocument
classes using the \DOMDocument::registerNodeClass() mechanism.
Parsoid's own phan configuration uses stubs for its abstract DOM
classes to encourage the use of "standard" DOM methods -- but core
doesn't use Parsoid's phan configuration and doesn't really understand
the way that ::registerNodeClass() works and so get confused by code
such as:
$el = $document->createElement('div');
In actual practice this is a Wikimedia\Parsoid\DOM\Document (a
subclass of \DOMDocument) which creates a
Wikimedia\Parsoid\DOM\Element (a subclass of \DOMElement) via the
::registerNodeClass() mechanism, but phan sees only the base
\DOMDocument::createElement() signature and assumes this creates a
\DOMElement *not* a Wikimedia\Parsoid\DOM\Element. If you do
"element-y" things on this, phan has no complaints, but if you pass
this back to a Parsoid method which expects the abstract
Wikimedia\Parsoid\DOM\Element type then phan (spuriously) complains.
This type error can be hard to understand.
Workaround this issue by simply aliasing Parsoid's abstract DOM types
to the built-in \DOMDocument etc types. The alternative would be to
use Parsoid's stubs, but it seems cleaner (for now) to avoid reaching
into
vendor/wikimedia/parsoid/.phan/stubs
to get them.
Change-Id: I90b33c5d65bde1582be9a452a144808b6d53d914
|
||
|---|---|---|
| .. | ||
| AllowDynamicProperties.php | ||
| DomImpl.php | ||
| README | ||
| Socket.php | ||
| WeakMap.php | ||
These stubs describe how code that is not available at analysis time should be used. No implementations are necessary, just define the classes and their methods and use phpdoc to describe what arguments are allowed.