Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] type pattern matching

Hi Oege -

> Let me just try to summarise what I understood
> from your message - please tell me if I go wrong!

Realize that I am just (a) restating the docs; (b) stating
what ajc does or should do; and (c) speculating on the rationale.
I believe that means any AspectJ user could/should come up with the
same answers by reading the docs and experimenting with ajc.
Otherwise, we have a doc bug (perhaps something unstated) or an ajc bug.
(Put another way: the goal is not to require AspectJ experts, but
to have a standard discernible by all.)

I'm assuming when you say "classes", you mean "types", when you
say "patterns" you mean "type patterns", and when you say "full jvm
name" you mean "fully-qualified type name".

Re:
> When matching a pattern P:
...
>     - first use normal java lookup
>     - if that fails, check whether there exists an

I think AspectJ and Java both first treat a name as fully-qualified,
and if that fails, they use imports and name scoping.  (Classes in the 
default package end up forming a special case, and have been 
discouraged of late as a result.)

>       [question: does this search range over everything on
>        the classpath?]
Pointcuts match join points; as the implementation appendix explains, 
affected join points must be under the control of the implementation.  
For ajc, that means as input source files or classes on the inpath, 
with something similar for weaving class loaders (though to the user 
these are "on the classpath").

Ajc can flag when an exact type (pattern) on the classpath is not in 
the control of the implementation (if the affected join point requires
control of that type).

So e.g., that means that when the declaring type patterns are matched 
for method-call pointcuts, the types may include anything on the
classpath (but in practice are matched against the set of declaring 
types of actual call join points).  That's a case where the type itself
need not be under the implementation control when matching the join point.

re:
> When you have a type pattern expression like
> 
>    (A.B1 || A.B2*).C

That's illegal (if C (being capitalized) is a simple type).  Nothing in the 
syntax permits || or &&  within a type pattern; however, a type pattern may 
be composed with other type patterns, with each pattern matching a type.  
So it is legal to say

    (Foo || Bar).main(String[])

Each type pattern should be matched separately and the results
combined by intersection or union.  I see no reason for one to affect
the other except by combination.  Indeed, I would expect some 
inefficiency in failing to look ahead, e.g.,

   staticinitialization(com.company.* && *..Foo)

But I imagine that could be fixed internally by type pattern rewriting.

re:
> * if P does contain a wildcard, P is matched
>    against the names of all classes [two questions:
>      names = any suffix of full jvm name?
>      all classes = everything on class path?]

>      names = any suffix of full jvm name?

I'm not sure why you'd say we're matching suffixes or prefixes
rather than the fully-qualified type name.   *Foo would match a suffix and
com..* a prefix and com..Foo an infix -- of the fully-qualified name.  
The type names being matched are always fully-qualified; it's just that 
simple exact type pattern names get a bit of extra help with Java lookup.  

>      all classes = everything on class path?]
Same as comment above.

Some confusion might come from trying to generalize about patterns
outside the context of pointcut matching.  First you wanted type patterns
to behave like method/field patterns, and now you want method-call
declaring type patterns to behave like method-execution declaring
type patterns.  As I understand it, one of the reasons AspectJ does not 
have named type patterns is because they mean different things in 
different contexts, which would make them more macro-like and 
confusing to programmers (here's where I wish Erik would chime in *smile*).

Wes

> ------------Original Message------------
> From: Oege de Moor <Oege.de.Moor@xxxxxxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Wed, May-10-2006 2:36 AM
> Subject: Re: [aspectj-users] type pattern matching
>
> 
> Thanks, Wes.
> 
> Let me just try to summarise what I understood
> from your message - please tell me if I go wrong!
> 
> When matching a pattern P:
> * if it does not contain a wildcard,
>     - first use normal java lookup
>     - if that fails, check whether there exists an
>       invisible type whose fully qualified type name is P
>       [question: does this search range over everything on
>        the classpath?]
> * if P does contain a wildcard, P is matched
>    against the names of all classes [two questions:
>      names = any suffix of full jvm name?
>      all classes = everything on class path?]
> 
> The above just applies to patterns without logical
> combinations in them, and wildcard means "*" or "..".
> 
> When you have a type pattern expression like
> 
>    (A.B1 || A.B2*).C
> 
> is that matched the same as
> 
>    A.B1.C || A.B2*.C
> 
> that is (A.B1.C) with java lookup, and A.B2*.C with the other
> rule?
> 
> Cheers,
> 
> -Oege
> 
> On Tue, 9 May 2006, Wes wrote:
> 
> > Hi Oege -
> >
> > I wasn't the decider so I can't speak to the actual reasons, but I 
> think
> > it comes down to the programmer most likely expecting exactly 1 match 
> when
> > writing an exact simple type name.
> >
> > Yes, simple exact typepatterns - type names - use Java type 
> resolution.  The
> > scoping  rules serve to disambiguate two simple type names.  This is 
> a
> > convenience to the programmer to use simple rather than 
> fully-qualified type names.
> >
> > I think your question comes down to this: when matching simple type 
> names,
> > AspectJ typepatterns do not match inaccessible types "available" via 
> import.
> > (Such inaccessible types match when fully-qualified, whether 
> specified as
> > exact type or as wildcarded.)  I believe that ignoring access 
> specifiers will
> > make it ambiguous, i.e., "match" more than one type using a simple 
> name.
> > I think it is unlikely that's what the programmer intended.  Another 
> way of
> > saying it: when using exact types (simple or otherwise) the 
> programmer can
> > expect to match at most one type.
> >
> > However, not all ambiguities are resolved via this scoping;  ajc 
> should still
> > flag when there are ambiguous exact simple type names.
> >
> > Perhaps related, below is a compiler bug.  When the simple type name 
> Foo is
> > resolved via two imports, the pointcut fails to match anything.  When
> > either of the import statements is removed, the pointcut matches.  I 
> would
> > expect an error saying that the type Foo is ambiguous when Foo is 
> resolvable
> > via more than one import (this is what Java does).  Once that behaves 
> correctly,
> > then we can get to the "Bar" case below where access modifiers might 
> disambiguate.
> >
> > Then your counter-argument might be that AspectJ should ignore access 
> specifiers
> > and not disambiguate those simple exact types, for consistency with 
> other
> > pointcut matching that ignores access specifiers. The use-case is 
> that
> > a simple type name won't match a single private type.  But the 
> programmer would
> > notice and correct this (assuming the XLint warning about the exact 
> type not matching
> > is enabled) by using a fully-qualified type name or pattern.  Since 
> this can be
> > stated, it seems to come down to trading off the programmer 
> disambiguating
> > multiple private types when using exact simple names versus 
> fully-qualifying a
> > simple type when it doesn't match due to access controls.  I think 
> that once
> > you decide to use Java import scoping, it's clearer to follow Java 
> rules since
> > there is an AspectJ workaround than to use hybrid rules.  I also have 
> a feeling
> > that the hybrid rules might be harder to implement since you can't 
> rely on an
> > existing implementation for Java.  But perhaps Gregor would prefer 
> the simpler
> > rule that pointcuts are never constrained by access modifiers, even 
> when using
> > shortcut forms like simple exact type names.
> >
> > It's an interesting case!
> >
> > hth - Wes
> >
> > ---------------------------- misc/PType.java
> >
> > package misc;
> >
> > import misc.PType.*;
> > //import misc.PType2.*;
> >
> > public class PType {
> >    public static class Foo {
> >        public static class Bar {}
> >    }
> > }
> > class PType2 {
> >    public static class Foo {
> >        private static class Bar {}
> >    }
> > }
> > aspect PType_A {
> >    declare warning: staticinitialization(Foo) : "Foo";
> > }
> >
> >
> >> ------------Original Message------------
> >> From: Oege de Moor <Oege.de.Moor@xxxxxxxxxxxxxxx>
> >> To: aspectj-users@xxxxxxxxxxx
> >> Date: Tue, May-9-2006 10:13 AM
> >> Subject: [aspectj-users] type pattern matching
> >>
> >>
> >> I am a little confused by the docs at:
> >>
> >> 
> http://www.eclipse.org/aspectj/doc/released/progguide/semantics-pointcuts.html#type-patterns
> >>
> >> In particular, what type names are candidates for
> >> matching type patterns that contain wildcards? All
> >> full jvm names of weavable classes? Or just any
> >> name of a weavable class, whether full jvm name or not?
> >>
> >> What is the reason that exact type patterns follow
> >> the rules of Java lookup in matching, whereas
> >> exact method patterns do not (one can match private
> >> methods)? It seems AspectJ uses at least three
> >> different views of matching patterns
> >> * for `exact' type patterns that happen to be type names
> >> * for type patterns that contain wild cards
> >> * for method and field patterns (whether exact or not)
> >>
> >> It would be interesting to know how that came about,
> >> and what the precise intended rules are.
> >>
> >> There is a discussion on a closed bug that is relevant:
> >>
> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=73073
> >>
> >> But that does not state what set of names are candidate
> >> matches for patterns with wild cards. Furthermore, it
> >> explains *what* the design does for exact type patterns,
> >> but not *why* it does that.
> >>
> >> Any thoughts?
> >>
> >> -Oege
> >>
> >>
> >> _______________________________________________
> >> aspectj-users mailing list
> >> aspectj-users@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> 



Back to the top