From the above,Aspect-oriented programming (AOP) is a new programming technique that allows programmers to modularize crosscutting concerns (behavior that cuts across the typical divisions of responsibility, such as logging). AOP introduces aspects, which encapsulate behaviors that affect multiple classes into reusable modules. Q: Wait a sec, Tcl isn't OO, so why do we care?A: While the OO paradigm seems to have been the birthplace of AOP, procedural programming could benefit as well. Tcl's introspective abilities could be put to active use to help realize this exciting technique even in the absence of a core-level object system.Discuss!RS: From the above, I'm not sure whether AOP is another solution (worth looking at for Tcl) or just another conditional problem (like another zipper to open the OOP straitjacket a little bit :^). How about Success Oriented Programming (use whatever language, paradigma, toolkit etc. leads you fastest to successful completion of the task) instead? And even non-OOP/AOP-users still have a right to deal with objects and aspects :)NEM: AOP seems interesting in terms of increasing modularity. There's a huge number of buzz-words associated with it, though. I've also yet to come across an example which doesn't involve logging.MSW: Or which can't be done by trivial operations without buzzword wikiwiki by simply mixing stuff into objects/classes/whatever at runtime, as well as tweaking method combination, as each serious OO framework supports. Of course it might be worth for those as unflexible as those of Java or C++... I don't think it's worth thinking about it in Tcl, as we don't need a buzzword to do that, we just tweak anything we like ? :)You might say (or ISTM) that AOP is the desperate attempt of Java-like OO Frameworks to adopt some of the strengths of CLOS like OO frameworks without getting all of the benefit, and without junking all of their own heritage... "business" as usual...IL: Consider event registration via aspects? For instance, I have a set of procedures that I want chaining of. Defining the path via declarations creates the code base we're trying to avoid. Event paths organized into one location provide a very concise organization of what is usually a "try to get the big picture" type of problem/concept. Wish I had something concrete to paste into here...APN: Have you looked at TOS [1]? Unfortunately no longer supported or actively worked on but seemed pretty well developed. Unfortunately, GPL and even more unfortunately (for the poor programmers working on it :) shelved in favor of a Java version. (AH The original pages are gone, but have been archived here [2].)RLH: I have heard a lot of the big wig Java folks say that AOP is nice but the added complexity is just not worth it. I have read several other posts that concur with what they said. That being said, someone likes it.Artur Trzewik : XOTcl has build-in support for AOP as filters and mixins. The best example for AOP Programming could be adding to all sql-api methods calls protocolling without changing any classes/methods (the realisation and client). The core Tcl supports AOP in form of "trace add command" commands. I do not think that AOP is more that such examples.DLP: Okay, I'll jump in with some examples that I have used in Java. Two examples come from a web application using the Spring framework [3], that has a lightweight AOP model.The first example is to ensure that each controller (the code that runs to process a page template and provide the active content) is called with a valid user account state. This is done by declaring the relevant methods on the interface that the implement to an AOP construct that ensures that the authentication process is done. This authentication code can check status, redirect the caller to other pages, and generally manage the session state as needed, then send the call on to the original target when needed. Since this behavior is not coded in the controllers themselves, but rather attached via AOP magic, new controllers get the behavior by virtue of implementing the interface (which they do anyway). The declaration syntax allows a means to opt out for any specific controller.The second example allows me to control database transaction context in a similar fashion, by associating the transaction aware code with an interface. In my example, the interface is part of an event driven (thanks to Tcl for teaching me the value of that) sequence of components that perform successive steps of business logic on blocks of data. A key requirement of the design is for the components to be independent to the degree that the interaction is entirely specified by the interface between them. However, when you are processing a block of data (imagine sales records for a shift), you want the usual ACID transaction guarantees, and that is incompatible with such a loosely coupled design. AOP comes to the rescue by allowing me control the data in code that only understands the data and control the transaction that only understands transactions.On the other hand, in this moderately large system system (170,000 KLOC), these are the only cases where I thought AOP provided a better solution that something more direct. For example, we don't use it for logging ;) So, my personal opinion is that this concept is extremely useful, but only in a limited number of cases.I agree with Artur Trzewik that you could easily get the majority of the benefit of AOP with straightforward use of trace. My examples could be handled quite nicely with trace add execution, if I had some way to define the equivalent of a Java Interface. I have tried to figure out how to add such a concept to Tcl, without any OO layer, but I haven't had much luck.DKF: Logging is probably best not done through aspects as it is often useful to put in extra information other than just a record of the entry/exit of each function (and its args/result). AOP would let you do "noddy logging" but it's often a good idea to also log decisions as they're made, and AOP-based logging doesn't really operate at that granularity (it tends to operate at coarser or finer levels). But I'm not sure that these concerns apply outside the domain of logging.
