3 ms·

> Now we're using annotations to replace XML - we're writing code so we don't have to write code. It makes no fucking sense. It does though. Turns out that wr

by xienze 6y ago

> Now we're using annotations to replace XML - we're writing code so we don't have to write code. It makes no fucking sense. It does though. Turns out that writing XML configuration means you don’t get to take advantage of the context associated with an annotation. I.e., if I put @Inject on method something(X value) in class A, all the context of what type to inject and where comes along for the ride. In XML I have to explicitly specify every single bit of context, and oh yeah, if I rename “A”, “X”, or “something” I better fix that in the XML or my program will blow up. Not a good look for a programming language that already gets grief about being overly verbose! Annotations just flat out make the configuration part of the equation easier.

Supermancho 6y ago
> I have to explicitly specify every single bit of context, You still are doing that, just in a less clear way and a less debuggable way. Most other languages get along without meta-languages (there are some frameworks that are spring-like) because being explicit is better than being implicit.
- xienze 6y ago
  > You still are doing that, just in a less clear way and a less debuggable way. That’s debatable to a degree. If I put @Inject on a field it’s pretty clear what’s going on just from a quick glance of the source code. By contrast, I don’t know injection of some field happened _unless_ I take a gander at the XML config. And the debuggability of both approaches is the same, the injection manager is doing the same magic under the covers, only the configuration is different.
culturedsystems 6y ago
Wiring up dependencies via XML is indeed a bad idea for the reasons you specify. But if you're going to wire up dependencies in code, you don't need annotations. Java already has a method for declaring and providing dependencies for a class: writing and calling constructors, which is clearer and checked by the compiler.
sreque 6y ago
It's important to understand that spring gets around the wiring problem by being a system for declaring and using global variables. This turns out to be a fundamental waste of time, as the whole point of making things dependency-injectable in the first place was to avoid global variables. However, every spring bean is a global variable, and every bean reference, whether explicit or implicit via autowiring, is a reference to a global variable. Spring results in bad, un-modular, hard-to-debug, and hard-to-maintain wiring code. Just say "no" to runtime dependency injection frameworks.

by xienze 6y ago

Supermancho 6y ago

> I have to explicitly specify every single bit of context, You still are doing that, just in a less clear way and a less debuggable way. Most other languages get along without meta-languages (there are some frameworks that are spring-like) because being explicit is better than being implicit.

xienze 6y ago
> You still are doing that, just in a less clear way and a less debuggable way. That’s debatable to a degree. If I put @Inject on a field it’s pretty clear what’s going on just from a quick glance of the source code. By contrast, I don’t know injection of some field happened _unless_ I take a gander at the XML config. And the debuggability of both approaches is the same, the injection manager is doing the same magic under the covers, only the configuration is different.

culturedsystems 6y ago

Wiring up dependencies via XML is indeed a bad idea for the reasons you specify. But if you're going to wire up dependencies in code, you don't need annotations. Java already has a method for declaring and providing dependencies for a class: writing and calling constructors, which is clearer and checked by the compiler.

sreque 6y ago

It's important to understand that spring gets around the wiring problem by being a system for declaring and using global variables. This turns out to be a fundamental waste of time, as the whole point of making things dependency-injectable in the first place was to avoid global variables. However, every spring bean is a global variable, and every bean reference, whether explicit or implicit via autowiring, is a reference to a global variable. Spring results in bad, un-modular, hard-to-debug, and hard-to-maintain wiring code. Just say "no" to runtime dependency injection frameworks.