-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't treat class name literals as dependencies #47
Comments
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>
.
|
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). |
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). |
Thought some more about this, but if someone adds a non-existing |
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".
The text was updated successfully, but these errors were encountered: