Open djmattyg007 opened 8 years ago
As an aside to this, it would be nice if ParameterScanner
and MethodScanner
were able to handle non-class type declarations of any form.
It looks like there's a related issue with classes that have a leading namespace separator. MethodScanner
doesn't appear to detect this, and fails to pass the token onto ParameterScanner
. ParameterScanner
then uses NameInformation
to resolve the classname as if it is relative to the current namespace, rather than as an FQCN.
The issue is definitely with MethodScanner
. If you create a completely separate instance of ParameterScanner
and pass it just the tokens for a single parameter, including the leading T_NS_SEPARATOR
token, it will correctly identify the FQCN, and NameInformation
will correctly resolve it as an FQCN.
I've managed to create a patch to resolve the second issue, see #60. The original problem, incorrectly detecting scalar type declarations, is still an issue.
I had to re-submit the PR as #61.
This repository has been closed and moved to laminas/laminas-code; a new issue has been opened at https://github.com/laminas/laminas-code/issues/27.
I believe the issue is with
MethodScanner
and notParameterScanner
, as this is what is actually parsing the PHP tokens - it correctly ignores non-scalar type declarations such asarray
andcallable
. From what I can tell,string
,int
,bool
andfloat
are tokens of typeT_STRING
. As a result, the scanner believes they are classnames. This can result in classnames that simply don't exist.I'm not really sure how this can be worked around inside the scanner. As far as I can tell, no PHP version checks are performed on the code being parsed, which means there's no reliable way of detecting whether or not
string
is an actual classname in PHP <7.0 code, or a scalar type declaration in PHP >=7.0 code.Perhaps there needs to be some way to globally set the PHP version of the code being scanned?