You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far I have come up with the following solutions, neither which is very good:
Wrap DOMDocument and narrow return type of its methods – will require wrapping all other DOM classes (lot of work), and when new properties and methods appear, they will need to be covered as well.
Add some kind of PHPStan extension to use in the repo – probably will not be used by library consumers.
Make DOM classes in stubs generic, one parameter per class type that can be registered – since PHPStan does not appear to support default values for generic parameters, people would need to specify all classes even when they register only a subset of them or none.
Avoid registerNodeClass altogether, use stand-alone (friend) functions for the required functionality – not as convenient for library consumers (compare InnerHtml::get($article->getContent()) vs. $article->getContent()->getInnerHtml()) and worse discoverability (a method will be immediately visible in API docs).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I am trying to raise PHPStan level in PHP-Readability but I got stuck on
DOMDocument::registerNodeClass
. Now, it is a dynamic feature so it is understandable that PHPStan does not like it, see the simplified example on the playground but I still need to deal with it somehow.So far I have come up with the following solutions, neither which is very good:
DOMDocument
and narrow return type of its methods – will require wrapping all other DOM classes (lot of work), and when new properties and methods appear, they will need to be covered as well.registerNodeClass
altogether, use stand-alone (friend) functions for the required functionality – not as convenient for library consumers (compareInnerHtml::get($article->getContent())
vs.$article->getContent()->getInnerHtml()
) and worse discoverability (a method will be immediately visible in API docs).Beta Was this translation helpful? Give feedback.
All reactions