[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] Philosophical Questions
|
Well, the IDE can help here but only if the AspectJ code and the
refactored code are in the same IDE. The IDE alone is not enough.
Think about the following situation. One team of programmers writes a
software module. Another team (perhaps from other company) writes some
aspectJ code over that software. If the first team refactor their code
they cannot know that the second team need to refactor theirs too.
This problem could be solved using language construtcts. Suppose
AspectJ support a construct that allow to define a "pointcut
interface", a collection of abstract pointcuts without jointpoints and
without advice. The first team publishes (with documentation) this
"pointcut interface". Then writes a private "pointcut class", attaching
jointpoints to this "pointcut interface". When they refactor their
code, the IDE can update this "pointcut class" too as you propose.
The point is that the second team can write an "advice class" that
attach advice to the published "pointcut interface" ignoring the
private "pointcut class". So the refactoring is transparent to the
second team.
The first team not need to know that a second team is writing AspectJ
over their code. They only have to allow a possible second team do
their work. Of course the first team the power of decision about what
parts of their code can be "aspected" and what not. As a counterpart
the second team doesn't need to "control" the code of the first team.
This allow low coupling between the modules developed by the two teams
and they can work in paralell.
AspectJ currently has not this type of constructs but I think all of
this can be made with the current constructs of the language. The
problem is that the implementation of this stuff without appropiate
constructs will not be simple and elegant. Follows a quick and dirty
snipet of code:
public interface IAdvice
{
public String getAspectInterfaceId();
public String getPointcutID();
public boolean preDo(JointPoint p);
public void postDo(JointPoint p, Object r);
}
/* Manage a mapping between aspect interfaces pointcut and advices */
public interface IAdviceRegistry
{
/* It can be easy to extend this to several advices for a pointcut
*/
public IAdvice getAdviceForPointcut(String aspect_id, String
point_id);
public void setAdviceForAspectInterface(String aspect_id, String
point_id, IAdvice a);
}
public abstract aspect AspectInterface1
{
abstract pointcut p1(IMyContext c);
Object around(IMyContext c): p1(c)
{
Object r=null;
IAdvice
a=getAdviceRegistry().getAdviceForPointcut("AspectInterface1","p1");
if(a!=null)
{
if(a.preDo(thisJointPoint))
r=proceed();
a.postDo(thisJointPoint, r);
}
else
r=proceed();
return r;
}
}
aspect AspectClass1 extends AspectInterface1
{
pointcut p1(IMyContext c): a definition ;
}
Regards,
Enrique J. Amodeo Rubio
Ken Horn wrote:
Again, this is something an IDE can help with. The AJDE already knows what methods are affected, it just need to hook into the refactoring / model changes such that methods / join points entering or leaving a PCD should be subject to confirmation with the user. The user can then decide whether to add/remove the point to/from the pointcut. I expect the IDE's to catch up as AspectJ/the plugin matures.
Ken
"Frank Sauer"
<Frank.Sauer@trcinc. To: <aspectj-users@xxxxxxxxxxx>
com> cc:
Sent by: Subject: RE: [aspectj-users] Philosophical Questions
aspectj-users-admin@
eclipse.org
08/07/2003 19:20
Please respond to
aspectj-users
How is that different from metadata in an external file
going out-of-sync in this same scenario?
To me this seems to be a problem in *ANY* weaving tool.
Not with tags though, but I fail to see how that is AOP
because the tags themselves are still a cross-cutting
concern simply by their existence all over the place.
Frank
-----Original Message-----
From: Cedric Beust [mailto:cbeust@xxxxxxx]
Sent: Tuesday, July 08, 2003 2:14 PM
Cc: AspectJ Users
Subject: Re: [aspectj-users] Philosophical Questions
R. Dale Asberry wrote:
In what way is the pseudo-regexp pointcut matching fragile?
For example, if the developer renames or refactors their methods, the
pointcuts will no longer find them.
And if the concerns are well separated, the developer might not even be
aware that a certain pointcut is being applied to the method they are
modifying, and they will therefore not even have the option to update
the pointcut definition.
--
Cédric
http://beust.com/weblog
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
--
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users