4 ms·

> When reading such a method's source, there was absolutely no way to tell that code was going to get injected. This clearly makes it pretty awkward to handle.

> When reading such a method's source, there was absolutely no way to tell that code was going to get injected. This clearly makes it pretty awkward to handle. Yet considering that the compiler manages to figure out where code needs to be injected, one can ask: why does the programmer not get to see this information? This is not a fundamentally unsolvable problem. It is a tools problem. It's easy to imagine a programming environment where you can tell immediately which code gets injected where. Even in a dynamic system you should be able to see, on examining a function, what its current contents including injected code are. Some programming language features require proper tools support to be useful. This requires languages that want to introduce such features to be opinionated on the matter of what tools you can use.

samus 5y ago
In the end, it is deterministic, as you say. But it's also quite more involved than you imagine. It's a big pile of interceptors (and their proper ordering), bootstrap classes, autoconfiguration, component scans, layered property sources and some more. Lots of it is not immediately visible and you have to start to read Spring source code. And it gets worse if the project gets set up in a way that makes it hard to deal with. For example, not organizing packages by feature. Relying on component scans at the default package is also not exactly funny. When developing a Spring project, you indeed start to quickly appreciate the introspection feature that advanced IDEs like IntelliJ IDEA provide. Inspecting the application container at runtime is also possible, but it's a clear sign that your app got waay too complicated and has to be refactored.
- Firadeoclus 5y ago
  I'm sure there are existing systems for which this is quite involved. These are design choices, though. If the compiler can figure it all out and find everything, then so can an IDE, and make everything visible where it needs to be visible.
  - samus 5y ago
    The issue is that it can become very complicated very quickly, even when the IDE is able to figure it all out and present it in a useful way. Even with the best tooling, nonlocal control flow can't help but increase the WTF per minute[0]. [0]: https://www.osnews.com/story/19266/wtfsm/ https://www.osnews.com/story/19266/wtfsm/
    - Firadeoclus 5y ago
      If it does in fact become "very complicated" then maybe you are trying to achieve something that is very complicated. Good tooling takes the surprise out of nonlocal control flow, and can project it into local control flow on demand. To take it back to skrebbel's complaint, "methods defined far, far away", "absolutely no way to tell", "very surprising", "no indication whatsoever" -- all things that good tooling fixes because it can show you what gets injected where and why, when you need it (and show you a minimally intrusive reminder when you don't).

samus 5y ago

In the end, it is deterministic, as you say. But it's also quite more involved than you imagine. It's a big pile of interceptors (and their proper ordering), bootstrap classes, autoconfiguration, component scans, layered property sources and some more. Lots of it is not immediately visible and you have to start to read Spring source code. And it gets worse if the project gets set up in a way that makes it hard to deal with. For example, not organizing packages by feature. Relying on component scans at the default package is also not exactly funny. When developing a Spring project, you indeed start to quickly appreciate the introspection feature that advanced IDEs like IntelliJ IDEA provide. Inspecting the application container at runtime is also possible, but it's a clear sign that your app got waay too complicated and has to be refactored.

Firadeoclus 5y ago
I'm sure there are existing systems for which this is quite involved. These are design choices, though. If the compiler can figure it all out and find everything, then so can an IDE, and make everything visible where it needs to be visible.
- samus 5y ago
  The issue is that it can become very complicated very quickly, even when the IDE is able to figure it all out and present it in a useful way. Even with the best tooling, nonlocal control flow can't help but increase the WTF per minute[0]. [0]: https://www.osnews.com/story/19266/wtfsm/ https://www.osnews.com/story/19266/wtfsm/
  - Firadeoclus 5y ago
    If it does in fact become "very complicated" then maybe you are trying to achieve something that is very complicated. Good tooling takes the surprise out of nonlocal control flow, and can project it into local control flow on demand. To take it back to skrebbel's complaint, "methods defined far, far away", "absolutely no way to tell", "very surprising", "no indication whatsoever" -- all things that good tooling fixes because it can show you what gets injected where and why, when you need it (and show you a minimally intrusive reminder when you don't).