One of us is using terms wrong, because we're talking about different things.
You seem to be talking about accessing things through interfaces, so that one can change whatever is on the other side of the interface. For testing, for example.
I am referring to something that there is only one of, while the program is running, which holds state, and that all part of a program potentially have access to.
Even if a dependency is injected, if it has state, and all parts of the program could potentially access it, I would consider it global mutable state.
This is part of the problem with the 'don't use global mutable state' advice. If what you really mean is 'access state through interfaces', then that's what we should say.
So, to be concrete, in my use of the term, a file cache is global mutable state because
a) I don't want multiple caches, potentially with the same content, in my program. In fact, this would be bad enough that I'd like to be confident it can't accidentally happen. I understand that some caches don't need this guarantee, but some do.
b) All parts of my program that use a file, use the cache to retrieve it.
c) The contents (and therefore the behavior, most specifically the timing) of the cache depends on the history of the program up to that point.
However, my implementation, I access files through an interface, so it would be trivial to change implementation.
Dependency injection does not insulate you from the global mutable state. It is a way of managing containers for state (or other behavior). Those containers can have any boundaries within your program you choose, from global down to the most local (remember that 'global versus local' is a continuum, not a binary).
> Even if a dependency is injected, if it has state, and all parts of the program could potentially access it, I would consider it global mutable state.
Not all parts of the program could potentially access it - it's injected where it's needed but only where it's needed, if other parts of the program wanted access to it you would have to change them so that it was injected there as well.
It makes little substantive difference whether the import is in code or in a separate declaration. Little substantive difference to whether the state is global and mutable, that is. Don't misunderstand me as claiming dependency injection is pointless.
> You do not need interfaces for dependency injection
Yet each component is supposed to implement component/Lifecycle protocol... in other words, an interface.
And component is actually awful in practice. It may look neat in theory, but it's too simple and results in a mess not much better than it would be without it.
You seem to be talking about accessing things through interfaces, so that one can change whatever is on the other side of the interface. For testing, for example.
I am referring to something that there is only one of, while the program is running, which holds state, and that all part of a program potentially have access to.
Even if a dependency is injected, if it has state, and all parts of the program could potentially access it, I would consider it global mutable state.
This is part of the problem with the 'don't use global mutable state' advice. If what you really mean is 'access state through interfaces', then that's what we should say.
So, to be concrete, in my use of the term, a file cache is global mutable state because
a) I don't want multiple caches, potentially with the same content, in my program. In fact, this would be bad enough that I'd like to be confident it can't accidentally happen. I understand that some caches don't need this guarantee, but some do.
b) All parts of my program that use a file, use the cache to retrieve it.
c) The contents (and therefore the behavior, most specifically the timing) of the cache depends on the history of the program up to that point.
However, my implementation, I access files through an interface, so it would be trivial to change implementation.
Dependency injection does not insulate you from the global mutable state. It is a way of managing containers for state (or other behavior). Those containers can have any boundaries within your program you choose, from global down to the most local (remember that 'global versus local' is a continuum, not a binary).