Re: [aspectj-users] type pattern matching

["Wes" <wes@xxxxxxxxxxxxxx>]

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
>