[
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
pertype(staticinitialization(TypePattern)).
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
optimization.
Alternatively, we can promote pertype(staticinitialization(TypePattern))
as the idiom to
use in common use cases of logging etc.
Thanks.
-Ramnivas
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
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
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev
