[dragonwriter]

> Also one would say monkey patching on Python and Ruby frameworks is another way to do AOP.

IIRC—and it may have changed in the several years since I made use of it for this, but I don’t see why it would—the standard way to do AOP in Ruby is leveraging modules-as-mixins which are a core language feature, monkey patching is unnecessary (but since classes in Ruby are open, modules-as-mixins can be used to monkey patch classes provided by someone else just as easily as being done at class definition time.)

Aspect-oriented programming has annoying implementation in languages like Java which don’t natively support the right abstractions and where you are fighting the language to do it.

Its kind of unfortunate that those are also the languages also which do the most to shape people’s understanding of AOP.

[pjmlp]

Same outcome, different implementation, instead of compiler plugins or bytecode rewrite, it gets patched via the languages dynamism.

I would say not having language support is a king of way of language designers not approving of its widespread use.

If anything Java and .NET are slowly closing some avenues that make patching possible, like final really means final JEP in Java.

[dragonwriter]

> Same outcome, different implementation, instead of compiler plugins or bytecode rewrite, it gets patched via the languages dynamism.

While the robust dynamism of Ruby (or Python) can allow it to be used in a patching-like way, the only dynamism that is essential to the implementation is the dynamism of runtime polymorphism (common in statically-typed, AOT-compiled OO languages.) The language feature it relies on that C++ and Java don’t have is multiple inheritance that gets resolves to a defined order you can call back up from a concrete method with “super”. There is no reason a static OOP language that supports runtime polymorphism couldn’t support this; it wouldn’t even need to add overhead to compiled classes that don’t make direct super calls from their own methods.