Re: [aspectj-dev] pertypewithin() vs. pertype() association...

[Adrian Colyer <adrian_colyer@xxxxxxxxxx>]

This is exactly the kind of discussion we were hoping to provoke :)

You make a good case for the pros of the PointcutDesignator form. The 
design as documented (and mostly implemented in the tree) was a compromise 
between the (A) and (B) designs in the bug report. The "pertypewithin" 
name is clearly designed to give the illusion of symmetry as much as 
possible with the other designators (ie. the implicit pcd is the postfix 
of the perclause, within(..)).  The crux of the decision comes down to 
this: I believe that programmers most naturally understand the per-type 
instantiation model as creating one aspect per type, and types are a 
static property of a program. This is the model that 
pertypewithin(TypePattern) promotes. pertypewithin(Pointcut) actually says 
something a little different.... at most one aspect is created per type, 
and the creation occurs at a join point matched by the pointcut expression 
if there is not an aspect already in existence for "the type". "The type" 
is an interesting question - the enclosing type of a join point shadow is 
probably the right answer as Jim suggested, but that's a more subtle thing 
for programmers to understand than "one aspect per type".

Your post actually provides a really good demonstration of the issue: 
pertypewithin(<typepattern>) is actually quite different to 
pertype(within<typepattern>). As you know, an unqualified pointcut of the 
form within(xxx) is going to match a heck of a lot of join points - and 
you almost certainly don't want a test at each of them to see whether an 
aspect has been created yet. The equivalent of 
pertypewithin(<typepattern>) is actually pertype(staticinitialization<type 
pattern>).  And yet pertype(within<type pattern>) seems the natural thing 
to write. [As an aside, if we move to pertype(pcd) we should recognize and 
optimize the unqualified within case...), I'm sure it would be very 
common]. 

The abstract/concrete aspect scenario is probably the most painful loss to 
me. You can always override the perclause in a subaspect, but its not as 
elegant as providing a specification for an abstract super-pointcut.

Like many design issues, we have to feel a way between something that 
covers the most possible use cases, and something that is simple and 
intuitive to work with. 

I'd like to hear the opinions of others on this point too, so please jump 
in if you have an opinion one way or the other...

-- Adrian
Adrian_Colyer@xxxxxxxxxx



Ramnivas Laddad <ramnivas@xxxxxxxxxxxxxxx> 
Sent by: aspectj-dev-admin@xxxxxxxxxxx
24/01/2005 22:52
Please respond to
aspectj-dev@xxxxxxxxxxx


To
aspectj-dev@xxxxxxxxxxx
cc

Subject
[aspectj-dev] pertypewithin() vs. pertype() association...






I was wondering about the design considerations in choosing 
pertypewithin() over pertype() proposal discussed in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=48082. The pertype() 
proposal, especially the pertype(PointcutDesignator) version, seems to 
align better with the rest of the language.

Pros of pertype(PointcutDesignator) over pertypewithin(). Use of 
pointcut designator instead of type pattern allows
- Writing abstract reusable aspects with pertype() association, while 
deferring selection of types to derived aspects.
- Aligning with other per- associations that all take a pointcut 
designator ==> less things to learn
- Implementing all use cases of pertypewithin(<type_pattern>) by using a 
pertype(within(<type_pattern>)) association.

-Ramnivas

_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev