Don't treat class name literals as dependencies about dephpend HOT 4 CLOSED

from dephpend.

Yea, I know what you mean. It would probably not be good to just ignore those, always. But I want to be able to pick and choose. So having a dependency-type "name" or "constant" would be helpful, since then I could filter them out when I don't care about them.

I didn't even think about actual constants, by the way - but you are right, Foo::BAR and Foo::class are not so different. Except the latter doesn't require the class to exist or be loaded.

My use case is that some code may use class literals to implement a kind of soft dependency, registering classes by name and using reflection to instantiate them, only relying on some known interface when using the instances. This patterns is quite common in the code I work with, and I'd like to be able to ignore this kind of dependency, since it'S a lot less problematic than other kinds (even though I'd prefer it to go away as well).

from dephpend.

I just learned about "connascence" metrics [1] that differentiate between different types and dependencies. This goes into the same direction I was thinking in here: distinguishing different kinds of dependencies allows for more meaningful analysis of the dependency graph. For instance, dependencies on behavior (use) are transitive, while dependencies on names (mention) are not (or at least not always).

[1] https://en.wikipedia.org/wiki/Connascence

from dephpend.

Thought some more about this, but if someone adds a non-existing XYZ::class somewhere I would still want this to show up, especially when writing architecture tests. If there are exceptions those can still be filtered using regex provided by the dephpend option.

from dephpend.