[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
