[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspectj-dev] pertypewithin() vs. pertype() association...
- From: Adrian Colyer <adrian_colyer@xxxxxxxxxx>
- Date: Tue, 25 Jan 2005 10:50:42 +0000
- Delivered-to: email@example.com
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
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...
Ramnivas Laddad <ramnivas@xxxxxxxxxxxxxxx>
Sent by: aspectj-dev-admin@xxxxxxxxxxx
Please respond to
[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
aspectj-dev mailing list