Hi,
I'm using the phpdoc_types fixer and I have a class called Resource (with the R) used by my code. The fixer is always converting the phpdoc type annotations to "resource" with the lower version.
Here is an example code which is incorretly fixed:
/**
* The resource.
*
* @var Resource
*/
protected $resource;
I would expect the fixer to understand that in this case Resource is a class name, not the PHP internal type.
I'm using 5.6.30 with PHP CS Fixer version 2.2.0.
This issue also affects classes called:
Probably some differences between PHP versions, all test on 7.0.13
This is not a bug. This is intentional. Please turn off the fixer that does this, if you don't want that behaviour.
I see, is it possible to turn off the fixer only for specific files?
no, not currently.
cool, closing due to discussion
I would welcome an enhancement where the fixer checks if any of the keywords are imported as a class from another namespace (by using use) as well and if so skip the fixing. However lets only continue on this only if someone has the time to make such change ;)
Hi @SpacePossum, I guess using class_exists is not an option here. Which could be a possible approach? I'm trying to understand if it's something I could do with my basic knowledge of the code base :)
Hi :)
class_exists would indeed not work as we do not class load the code we are fixing.
Since we are looking at the Tokens we could look for Tokens that make up use-statements, similar as the NoUnusedImportsFixer finds those. Based on the findings we could do a bit of better fixing as we than we would know which classes are explicit imported. However this would be tweak and not a trivial thing to build.
I would welcome an enhancement where the fixer checks if any of the keywords are imported as a class from another namespace (by using use) as well and if so skip the fixing. However lets only continue on this only if someone has the time to make such change ;)
this approach would not cover case, when given class like Resource is in given subnamespace (but other file), as the import is not needed to be done
Indeed, these cases we do not know, i.e. not covered by than we would know which classes are explicit imported. Still it would be nice tweak as the ones that are explicitly imported by use statements are not fixed anymore, so perfect; no, but better ;)
naming sth after internal PHP class is bad practice anyway. I would accept such an improvement, but for me we could spent time on sth more important.
funny prio conflict with unused_use... ;)
Most helpful comment
naming sth after internal PHP class is bad practice anyway. I would accept such an improvement, but for me we could spent time on sth more important.
funny prio conflict with
unused_use... ;)