| Re: [aspectj-users] Philosophical Questions |
The "Obliviousness" property is essential to the definition of AOP, it loosens the coupling between classes and aspects. However, meta-tags appear a lot more convenient than writing a query. Tags although aren't oblivious, although they are loosley coupled to their aspects in that coupling is through an intermediary, that is the name of the tag.The tag however is now spread out throughout the code so maintainance may be a little bit more difficult. But, that doesn't mean that you can build in compiler technology to tell you where all the tags are. Also, on the same line of reasoning, you can build IDE technology that if you add a tag then it creates a new aspect or is added to an existing one.So in eclipse, you add a marker, which has a quick-fix that converts a tag to an aspect. Just like a quick-fix converts an undefined method into a defined one in another class.The reason why people like tags are for two reasons, the first is convenience (it takes less brain power to add a tag), second its localized in text, you can see at a glance which aspects apply at a given point. In both cases, the problem can be fixed with appropriate IDE technology.This brings us to a bigger question, should a programming language be embelished with constructs to compensate for the lack of IDE support?Assuming I understand what you mean by marker interface, then I think mean property based pointcuts are often, but not necessarily different.For me, classic property-based pointcuts are:call(public * com.us.foo..*.*(..))execution(CertainValue *.*(..))args(.., ParticularValue, ..)In other words, they are a way of using wildcards that are extremely stable, because they are based on a deep and stable property of the join points. The first, public interface, is one of the best examples.As I see it, both property-based and enumeration-based pointcuts have complete non-invasiveness (aka obliviousness), and that is a key property. You don't have to touch the target source to be able to write the pointcut and advise it.Attributes or tags, ala JSR-175 do require access to the target source, and this is one of their limitations.Now what about marker interfaces. If the marker interfaces are already there, in other words you don't have to go add them before you write the pointcut and advice, then I would claim that those are property based pointcuts. They have the non-invasiveness property.So some ways of using marker interfaces probably fall into the notion of property-based pointcuts, and others don't. I guess these concepts crosscut each other.-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Merrick Schincariol
Sent: Monday, July 07, 2003 7:35 PM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Philosophical Questions
Gregor,Just so I understand your terminology: property-based pointcuts involve selection via marker interface and enumeration-based pointcuts involve explicit class patterns?This is an interesting change in view. My impression from following AspectJ lists before is that metadata and even static inner aspects are still the same close coupling we had before, only adjacent to the mainline code instead of embedded within it. Is this just a measure of practicality, or is there some real benefit to highlighting aspects directly in Java classes? I can certainly see it easing the transition for developers, but I'm worried that it can get out of control quickly. If you look at the .NET metadata usage for XML binding, for example, there are so many metadata tags that it distracts from the underlying code.Cheers,Merrick-----Original Message-----
From: Gregor Kiczales [mailto:gregor@xxxxxxxxx]
Sent: Monday, July 07, 2003 1:54 PM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Philosophical Questions
From Merrick Schincariol
Sent: Saturday, July 05, 2003 8:03 AM
1) Can Aspects themselves be broken down into smaller sub-components?Most of the Java AOP frameworks break out aspects into a number of different pieces. For example, you implement your advice as one Java class, your introductions as another and then define (usually using XML) the pointcuts and the relationships between the components. So one Aspect could actually require many files to implement and define. Does the complexity of this approach interfere with the AOP philosophy? My fear is that when the implementation requirements are complex, from a language point of view, you start to lose track of the problem you are actually trying to solve.2) Can pointcuts be modeled separately from advice?This follows on the above point, but it's one that I find a little odd. Most (all?) of the pure Java approaches define their pointcuts in one file and their advice in another. Presumably this means that advice can be reused across multiple different aspect definitions. From a philosophical point of view, can advice be modeled truly independently from pointcuts? I would think that certain types of advice, particularly when dealing with cflow and other advanced join points, really require the pointcut definition to be present in order to make sense.One of the guiding principles of the AspectJ design was that we were trying to enable modular implementation of crosscutting concerns -- aka aspects. That is what led us to put pointcuts, advice and other member declarations together into aspects. For example, being able to see the entire ObserverProtocol aspect in a single screenful of code was important to us. It gave us the nice modularity we were after. I personally believe that is critical, that's what separation of concerns is about, getting the concerns into separate modular pieces.From that perspective, putting pointcuts and advice bodies in separate files isn't what we want.But what I don't understand is to what degree tool support will be able to bring the separate things back together. One of the claims about XML and meta-data is that of course you'll never edit the raw meta-data or XML, there will be tool support. If there is tool support, then that support might be able to make things look more modular. But then again, everytime I see someone talking about XML they insist on showing me the raw XML, so I'm not sure how present the tool support is.3) What role, if any, should metadata play in AOP?
I know Gregor has commented on the use of metadata a couple of times, but the JBoss group is charging ahead with their "AOP" product which encourages developers to use class metadata to load library aspects. This strikes me as wrong in many ways, but the message that is reaching the development community is that interceptors and metadata are all you need to do AOP. Is this just a function of what's easy to implement, or are people really having trouble grasping the concepts?
My opinion on this has softened. I now believe that meta-data support (ala JSR-175) is useful, and that when it appears in Java, tools like AspectJ should support it instantly. I think programmers should use attributes (aka tags or metadata) in pointcuts in certain circumstances when property-based or enumeration based pointcuts are not appropriate. Without going into detail, I think the 3 cases are:- if the pointcut reaches a large number of join points, use a property based pointcut- if the pointcut reaches a small number of join points, and a property-based pointcut is hard to write, use tags- if the pointcut reaches a small number of join points, and a property-based pointcut is hard to write, and you don't have access to the target source, then use an enumeration-based pointcut.