3 ms·

Connection pools, resource caches, file loads (a resource cache) have no need to be global. If you inject your dependencies (also known as partial application i

by zbobet2012 9y ago

Connection pools, resource caches, file loads (a resource cache) have no need to be global. If you inject your dependencies (also known as partial application in functional languages) you will find it far easier to test things in isolation, to decouple modules, and to refactor your software. The UI being global mutable state isn't actually true on all platforms (but is true on the web). And even then its possible to "hide" that to some degree in well designed frameworks. Never say never, but half of your examples _shouldn't_ be globally mutable state.

Animats 9y ago
Looking at my modern code on Github (not the stuff from the 1970s and 1980s I've revived), few projects have any global mutable variables at all. There are a few that are assigned once at startup. There's a timestamp. In Javascript work, of course, there's the DOM and other state that belongs to the browser. In some other Python code, I have some global objects which manage some data, but few or none standalone global variables. There just doesn't seem to be much need.
sago 9y ago
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).
- jeremiep 9y ago
  You do not need interfaces for dependency injection and it can also be done without global mutable state. This Clojure library is doing so beautifully with immutability: https://github.com/stuartsierra/component https://github.com/stuartsierra/component
  - klibertp 9y ago
    > 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.
- lmm 9y ago
  > 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.
  - sago 9y ago
    s/injected/imported 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.

Animats 9y ago

Looking at my modern code on Github (not the stuff from the 1970s and 1980s I've revived), few projects have any global mutable variables at all. There are a few that are assigned once at startup. There's a timestamp. In Javascript work, of course, there's the DOM and other state that belongs to the browser. In some other Python code, I have some global objects which manage some data, but few or none standalone global variables. There just doesn't seem to be much need.

sago 9y ago

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

jeremiep 9y ago
You do not need interfaces for dependency injection and it can also be done without global mutable state. This Clojure library is doing so beautifully with immutability: https://github.com/stuartsierra/component https://github.com/stuartsierra/component
- klibertp 9y ago
  > 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.
lmm 9y ago
> 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.
- sago 9y ago
  s/injected/imported 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.