Don't treat class name literals as dependencies

[Daniel Kinzler]

Class name literals, like FooBar::class, should not be treated as a dependency on the class FooBar. Such literals are really just syntactic sugar for string literals like "FooBar", they don't require the class to be loaded, or even to exist at all.

Technically, class name literals are a dependency on the class name, as they have to be updated when the class is renamed. If this kind of dependency should still be tracked, the mechanism for marking the dependency type suggested in #43 could be used to mark such dependencies as "name".

[Michael Haeuslmann]

Interesting way of looking at it 🤔 so you're looking at it from a technical point of view, I'm looking at it from the point of "if I'm borrowing a concept from another class, I have a certain relationship to that class/package." Of course some people do stuff like Numbers::ONE 😅 but if it's something like Validator -> Credit card::FORMAT I'd want to know about it. Do you know what I mean?

…

On Mon, May 13, 2019, 6:44 AM Daniel Kinzler ***@***.***> wrote: Class name literals, like FooBar::class, should not be treated as a dependency on the class FooBar. Such literals are really just syntactic sugar for string literals like "FooBar", they don't require the class to be loaded, or even to exist at all. Technically, class name literals are a dependency on the class *name*, as they have to be updated when the class is renamed. If this kind of dependency should still be tracked, the mechanism for marking the dependency type suggested in #43 <#43> could be used to mark such dependencies as "name". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#47?email_source=notifications&email_token=AAQRO7IGARRWKO7O63344K3PVFPDNA5CNFSM4HMPN4XKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GTNNGUQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQRO7JCAAANICY7FAQGFMTPVFPDNANCNFSM4HMPN4XA> .

[Daniel Kinzler]

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).

[Daniel Kinzler]

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

[Michael Haeuslmann]

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.