Oh my gotd are you building a straw man... If the only thing you see in AOP is functions accepting functions and returning functions, then - superficially speaking - AOP is, as you say, merely a wrapper for offering some functional-like features for (mostly) OO language... But man, are you wrong in proposing that AOP is *_just that_*.
All I see is that AOP uses these tools (that are indeed functional in their nature) to achieve separation of concerns and cleanliness of I've seen AOP used in many places where *not* using AOP would have otherwise polluted the actual code base with explicit implementation details of the completely orthogonal concerns like cacheing, transaction management, performance logging, security, etc. The premise of AOP is not that it allows to compose functions and do FP style stuff. I can do that in Java today (albeit it's somewhat more awkward than, let say ... umm ... scala) without any help from AOP. The premise of AOP is that it allows to divorce completely orthogonal concerns that cut across the entire cofde base from the main business logic in a cleanly separated manner. That is not to say, it one can not use other good engineering practices to achieve that goal, but this would be akin to using FP style in Java - doable but awkward. teisipäev, 20. detsember 2011 22:46.15 UTC+2 kirjutas KWright: > > I guess the biggest issue with AOP is that in 99% of cases it's used to > shoehorn FP concepts into a mostly-object-oriented-but-not-functional[1] > language. > > You take an object, you pick on some of the methods therein and wrap them > with around advice, before advice, after advice, etc. In FP these methods > can be treated as first-class concepts in their own right. You take a > function, pass it to a function, return a function; there's no need to > build these specialist constructs just to access methods that can only ever > exist within the context of an object. > > After all... In the kingdom of nouns, the only thing you can ever do with > a verb is execute it. Put verbs on an equal footing with nouns and you can > deal with them directly, no tricky marshalling required. > > > [1] Yes, mostly, primitives and static members are most emphatically *NOT* > object-oriented. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/RseCxDHCxtwJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
