Comment by lloeki
7 months ago
> AOP? (since aspect-oriented programming is history)
AOP is very much alive, people that do AOP have just forgotten what the name is, and many have simply reinvented it poorly.
7 months ago
> AOP? (since aspect-oriented programming is history)
AOP is very much alive, people that do AOP have just forgotten what the name is, and many have simply reinvented it poorly.
AOP always felt like a hack. I used it with C++ early on, and it was a preprocessor inserting ("weaving") aspects in the function entries/exits. Mostly was useful for logging. But that can be somewhat emulated using C++ constructors/destructors.
Maybe it can be also useful for DbC (Design-by-Contract) when sets of functions/methods have common pre/post-conditions and/or invariants.
https://en.wikipedia.org/wiki/Aspect-oriented_programming#Cr...
> AOP always felt like a hack. I used it with C++
Colour me surprised that a language which is the practical definition of bolted-on features has an implementation that feels like a bolted-on hack ;)
> early on
Also the "early" AOP was very much focused on a formal definition and a specific approach, further entrenched by how Java did it.
But you don't need to do AOP "by the letter" to do AOP: as long as you have cross-cutting concerns that you sprinkle over your code you're doing AOP, even if you're not calling that pointcut and stuff.
Python decorators, C# attributes, Ruby's whole "monkey patching" (e.g alias method chaining pattern, or simply modules combined with the ancestor system and message passing) are all pretty much variations that fit well with the AOP paradigm.
I'd argue that a lot of people are doing AOP without ever realising it.
Also very much alive and called that in the Java/Spring ecosystem