On Fri, Apr 26, 2013 at 11:54 AM, Archie Cobbs <arc...@dellroad.org> wrote:
> On Fri, Apr 26, 2013 at 11:31 AM, Matthew Adams > <matt...@matthewadams.me>wrote: > >> While the Java familiarity afforded by (a) is appealing, the verbosity is >> a turn-off for me. AspectJ pointcuts already are very terse and a bit >> cryptic for the uninitiated, so I'm not afraid of just continuing down that >> road with (b). >> > > Your suggestions in the (b) case are very reasonable. > Glad *someone* agrees... :) > Regarding the larger (a) vs. (b) question, the primary contributors will > have to make that call since they are the ones doing the work. > > Agreed. > Of course that won't stop me from throwing in a few personal opinions :) > > The phrase "terse and a bit cryptic" describes a bug, not a feature. > Perhaps I should've said "succinct and extremely powerful"? :) > Verbosity is a small price to pay for the ability to re-use the existing > Java syntax knowledge that 100% of AspectJ users will already have. > > Regarding implementing option (a).... since we're talking about a piece of > software that already knows how to compile Java expressions, implementing > option (a) is "just" a matter of hooking up that existing stuff and > applying it. I see no reason why the compiler couldn't compile these > expressions into bytecode/transient classes as it compiles, then attempt to > load and evaluate them during compilation. If this fails because the > expression is not compile-time evaluable, then just weave the expression > into the aspect and fall back to evaluation at runtime like it already does > with the existing annotation support. > > I'm sure I'm making sound easier than it is though. > > I have the same feeling that it does sound easier than it actually is. -matthew
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
