[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] pertypewithin() vs. pertype() association...

Good points!

I understand the efficiency issue with pertype(within(TypePattern)). Could this usage pattern
be optimized to be implemented exactly as pertypewithin(TypePattern)? I was thinking along
the following lines:
- within(TypePattern) capture many join points
- The first join point encountered is the one matched by staticinitialization(TypePattern)
upon loading the type
- Therefore, pertype(within(TypePattern)) can be treated as if user specified

In other words, the within(TypePattern) leads to eager creation of the pertype() aspects.
From usage point of view, the eager creation of aspect upon loading the associated type
will be still intuitive.

The other pointcut definitions could be left unoptimized until we see use cases that warrant an

Alternatively, we can promote pertype(staticinitialization(TypePattern)) as the idiom to
use in common use cases of logging etc.



Adrian Colyer wrote:

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

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

To aspectj-dev@xxxxxxxxxxx cc

[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.


aspectj-dev mailing list

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