You'll get N different definitions of AOP if you ask N people for them. Separation of concerns was actually coined (aside from dijkstra's original usage) by Peri Tarr for hyperspaces, which was focusing on functional concerns (just around multiple dimensions) and not the non functional concerns of AspectJ. But for functional concerns we have lots of direct options, while for non functional concerns we also have indirect options like garbage collectors. The space is quite big and well travelled.
Regardless of all the fuzziness around terminology, we still try to advance knowledge forward, improve the tooling, possibly improve language syntax, codify and/or formalize best practices.
Just wanted to agree, kudos to better tooling support being an important enabler of AOP (beyond research prototypes, that is). It is not separation of, but cross cutting concerns what is highlighted, i18n, logging, error handling, target platform, etc., all with potential variations. While these commonalities are usually dealt with by throwing them to a library, the interactions of the alternative layers (there will be since they are going to be heavily coupled by the very definition of "cross cutting") is better dealt with, or could potentially hurt less using some version of AOP ideas (EDIT deleted FODA reference).
Right. The main question in our field is whether the term "AOP" is useful or not. The current popular thinking is that it is not very useful, but modularity, as always, is a great concept.
Comments
You'll get N different definitions of AOP if you ask N people for them. Separation of concerns was actually coined (aside from dijkstra's original usage) by Peri Tarr for hyperspaces, which was focusing on functional concerns (just around multiple dimensions) and not the non functional concerns of AspectJ. But for functional concerns we have lots of direct options, while for non functional concerns we also have indirect options like garbage collectors. The space is quite big and well travelled.
This is true for many computer industry concepts:
"object-oriented", "functional programming", "garbage collection", "big data", "programmer", "hacker", "technical debt", etc.
Regardless of all the fuzziness around terminology, we still try to advance knowledge forward, improve the tooling, possibly improve language syntax, codify and/or formalize best practices.
Just wanted to agree, kudos to better tooling support being an important enabler of AOP (beyond research prototypes, that is). It is not separation of, but cross cutting concerns what is highlighted, i18n, logging, error handling, target platform, etc., all with potential variations. While these commonalities are usually dealt with by throwing them to a library, the interactions of the alternative layers (there will be since they are going to be heavily coupled by the very definition of "cross cutting") is better dealt with, or could potentially hurt less using some version of AOP ideas (EDIT deleted FODA reference).
Right. The main question in our field is whether the term "AOP" is useful or not. The current popular thinking is that it is not very useful, but modularity, as always, is a great concept.