Re: [aspectj-users] Unknown AspectJ Error Message

[Oege de Moor <Oege.de.Moor@xxxxxxxxxxxxxxx>]

I won't repeat the discussion on Bugzilla, except to note that
it is indeed an enhancement request for ajc. Hopefully the
abc implementors can be forgiven for implementing their
own enhancement requests in abc :-)

Of course Wes is right in his worries about compatibility
between ajc and abc; it is important not to cause confusion about
the language definition. There is a short and precise
description of all differences between ajc and abc at

http://aspectbench.org/differences

One of these is major, namely that abc does not support
separate compilation of aspects.

The other differences are confined to small corner cases
in the language design, in particular where we couldn't
find a tight specification in the docs. All new features
available in abc are explicitly controlled by
commandline switches.

For every difference, if there is a good technical reason
why current ajc behaviour shouldn't be changed, we'll move
it under a cli switch.

If anyone finds unlisted differences between abc and ajc,
please report them on the abc bugzilla at

http://aspectbench.org/cgi-bin/bugzilla/index.cgi

Thanks!

-Oege


On Thu, 28 Oct 2004, Wes Isberg wrote:

> I don't think Maximilian's pointcut is ambiguous; it looks
> like ajc is finding ambiguity where there is none, so the
> error message is a bug in the implementation of the current
> policy to disallow ambiguous bindings.
>
> Now, should AspectJ use ordering to eliminate the ambiguity?
>
> In the bug cited, Oege suggests using pointcut expression
> ordering to disambiguate alternate bindings (and to
> implement short circuits, etc.)  (For developers, the issue
> of pointcut evaluation order typically comes up when if(..)
> code has side effects, which is bad style but not illegal.
> We generally provide no guarantees about ordering.)
>
> I'd be interested in hearing from Gregor, Jim, or Erik on
> this point.  I remember order of pointcut evaluation being
> one of those areas in the language design that was purposely
> (but not expressly) left undetermined, because imposing that
> requirement would restrict implementations in important ways.
> (hand-waving here)
>
> This is also a tricky compatibility point: the abc compiler
> is touted as implementing the "same" AspectJ language.
> But in this case, a program compiled with abc won't compile
> with ajc, for reasons that are, for the moment, intentional
> on ajc's part and which have their policy stated in the
> programming guide.  This might be a good enhancement request
> (particularly since it wouldn't break backwards compatibility),
> but that's all it is at present, and it cuts against our
> best-available language documentation.  (As for the test suite,
> it has mostly regression cases for bugs submitted over the years,
> but we have not had the resources to do a principled suite
> covering all aspects of the language.  This would be a great
> area for contributions.)
>
> It seems like abc is designed to experiment with extensions
> and variants of AspectJ, so it is a good place to work out
> issues with the language.  But we will have to be careful to
> avoid people confusing these language variants with AspectJ.
> One form of that confusion would be to present something as
> a "bug" in AspectJ that abc "fixes".  In this case, the
> consensus might turn out to be that it is a bug and Oege's
> suggestion is the correct semantic fix.  It's just that we
> (or perhaps just "I") don't know that yet.
>
> Wes
>
> > ------------Original Message------------
> > From: Oege de Moor <Oege.de.Moor@xxxxxxxxxxxxxxx>
> > To: aspectj-users@xxxxxxxxxxx
> > Date: Thu, Oct-28-2004 6:50 AM
> > Subject: Re: [aspectj-users] Unknown AspectJ Error Message
> >
> >
> > Hi, this is a consequence of the fix described in
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=61568
> >
> > abc is a research compiler for the same AspectJ language
> > as ajc; it's been developed with the same test suite.
> > There are however some minor differences, and one of
> > them is that abc does not place such restrictions on
> > || and variable binding. Your pointcut would be fine
> > in abc. See
> >
> >   http://aspectbench.org
> >
> > -Oege
> >
> > On Thu, 28 Oct 2004, Maximilian Stoerzer wrote:
> >
> > > Hi everybody,
> > >
> > > when applying advice to an inner class I get the following error
> > message (quote):
> > >
> > > Cannot use this() to match at this location and bind a formal to type
> > >
> > 'org.apache.commons.codec.language.DoubleMetaphone$DoubleMetaphoneResult' - the
> > > formal is already bound to type
> > >
> > 'org.apache.commons.codec.language.DoubleMetaphone$DoubleMetaphoneResult'.  The
> > > secondary source location points to the problematic this().
> > >
> > > The corresponding pointcut definition is the following:
> > >
> > > public pointcut contextCall_ (char param_0,
> > >
> > org.apache.commons.codec.language.DoubleMetaphone.DoubleMetaphoneResult refObj)
> > > (execution(public void
> > >
> > org.apache.commons.codec.language.DoubleMetaphone.DoubleMetaphoneResult.append(char))
> > >   && args(param_0) && this(refObj)) || (execution(public  void
> > >
> > org.apache.commons.codec.language.DoubleMetaphone.DoubleMetaphoneResult.append(char,
> > > char)) && args(param_0, char) && this(refObj));
> > >
> > > (looks a bit odd because it is generated).
> > >
> > > Has anyone experienced this kind of error before? What is the problem
> > here? I have
> > > to admit that I do not understand the error message.
> > >
> > > Thanks for any hints!
> > >
> > > Best regards,
> > > 	Max
> > >
> > > --
> > > Maximilian Stoerzer
> > > Lehrstuhl Software Systeme - FMI - University of Passau
> > > Tel: +49 851 509 3096, eMail: stoerzer@xxxxxxxxxxxxxxxxx
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> > >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>