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. Regarding the larger (a) vs. (b) question, the primary contributors will have to make that call since they are the ones doing the work. 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. 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. -Archie -- Archie L. Cobbs
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
