Re: [aspectj-users] type pattern matching

["Wes" <wes@xxxxxxxxxxxxxx>]

re: https://bugs.eclipse.org/bugs/show_bug.cgi?id=73073

I think the suffix matching is just a bug.  It's matching not only with the simple 
name (e.g., A*) but with any suffix (e.g., Aspect.A*.foo() for fully-qualified
type testing.Shadowing.TestAspect.A).  Whether it matches within scope or 
all types available to the weaver is beside the point.

The bug could be major because people could be relying on it, and making it correct
could break a lot of programs.  It also hides a number of syntax errors;
e.g., A* (types starting with A) should perhaps be A.* (nested types of A).

So, what should it do?  We might not want to require every wildcard pattern
to match only fully-qualified names; the rule would be simpler and there is a 
workaround for most cases (i.e., *..A*), but I think we want(ed) to do it more
like the programmer would expect, which is to use type names as in Java.

I don't have time to look for the JLS language, but there must be distinctions 
among the kinds of type names, like:

  - fully-qualified names (include package)
  - exact type names 
    - simple - unqualified type
    - enclosed - qualified with some enclosing types
      - fully-enclosed - qualified with all enclosing types

That means a type can be referred to in many ways in Java programs:

  - fqn: im.testing.Shadow.TestAspect.A
  - unqualified type names:
    - simple: A
    - enclosed: TestAspect.A (and those fully-enclosed)
      - fully-enclosed: Shadow, Shadow.TestAspect, Shadow.TestAspect.A

I can see treating AspectJ wildcard patterns as also matching any exact type name,
but not just any suffix.  Under this rule, A* matches TestAspect.A but 
Aspect.A* would not match TestAspect.A; nor would testing..A* match anything
(for lack of im..* pattern prefix).  That's a restriction over the current
implementation that would cause some existing pointcuts to break, but I 
don't know that there would be many intentional uses of implicit suffix
matching.

This rule is a little like the reality of matching against multiple join point 
signatures: the same thing can go by different names in Java.  However, it 
does require that we can determine the package of a class from its name,
and I'm not sure we have that information; since capitalization is a 
convention, not a requirement, the information is not in the name itself.  
I can imagine if not remember Erik being sheepish on this point - matching 
suffixes in order to match the exact type names.  That could probably be 
refined to segments, which would still include packages (which cannot be 
used as such in Java).  Yuck.

To sum up, I think that to permit some simple type names in wildcards, 
the implementation is permitting any suffix.  This is bad, but might be
impossible to fix.  We might be able to restrict it to segments, but that
still leaves the package case, e.g., testing.Shadow.TestAspect.A matching
even though that name cannot be used in a Java program.

> Just to be clear, I never said I wanted anything; I'm merely asking
Sorry, I was writing loosely when I said "you"; your question expected as
much, and it was a reasonable expectation.

Thanks for bringing this up.  It makes me wish Java used '-' to distinguish
package and class names.

Wes

> ------------Original Message------------
> From: Oege de Moor <Oege.de.Moor@xxxxxxxxxxxxxxx>
> To: wes@xxxxxxxxxxxxxx, aspectj-users@xxxxxxxxxxx
> Date: Wed, May-10-2006 10:19 AM
> Subject: Re: [aspectj-users] type pattern matching
>
> 
> Thanks for your patience.
> 
> <on matching patterns with wildcards against type names>
> >I'm not sure why you'd say we're matching suffixes or prefixes
> >rather than the fully-qualified type name.
> 
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=73073
> 
> Type pattern "A*"  matches fully qualified name 
> "ShadowingAndAccess.Aspect.A", and it seemed to me A* actually
> matched the suffix A.
> 
> It might be that matching with wildcards also takes the current
> scope into account. However, if that were true, adding a * to
> a pattern can never stop it matching. This is however what happens
> in the following program:
> 
> ------------------------------------------
> import test2.A.*;
> aspect X{
>      // replace B* by B to get a match
>      pointcut pc() : call(* B*.foo(..));
>      after () : pc() {
>          System.out.println("matched");
>      }
> }
> ------------------------------------------
> package test2;
> public class A {
>      B b= new B();
>      public class B {
>        public void foo() {}
>      }
>      public static void main(String[] args) {
>        new A().b.foo();
>      }
> }
> -------------------------------------------
> 
> I'd be most grateful for an explanation that includes both examples.
> 
> > 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.
> 
> Just to be clear, I never said I wanted anything; I'm merely asking
> what the intended meaning is, just in case ajc doesn't exactly
> implement that meaning. Probably I'm just not reading the docs
> carefully enough!
> 
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>