Hi, > Thanks for the reply Andy, and it's great to know that you have already been > thinking about these things. Were you thinking along the lines of a general > purpose template-style meta-programming facility? I.e. aspects that target > the source -- grabbing AST context in a pointcut, etc. Or just implementing > specific features literally? Getter/Setter seems like it would be easiest > to implement in a template-style solution, but the ? operator and certainly > val would be more difficult. Although I don't know. I think both the ? and > val are pretty easy "sugars" so perhaps they too could be satisfied in a > general template based approach.
I think realistically if the features were to be implemented anywhere in the near term they would be implemented directly. Time/resource constraints limit the ability to build a general compiler plugin mechanism for aspectj, the best we might be able to manage is sorting out APT support and then lombok could be used directly. I believe the code has to be compilable with javac in the first place, so something like "?." could not be done this way, it would need a direct implementation (with modified grammar). > I don't think that these kinds of ideas are outside of the spirit of > AspectJ. In our group, we have migrated to almost exclusively using > annotations in pointcuts -- so our junior/average developers don't have to > even look at any AspectJ syntax, but we get the power. Such a > meta-programming facility would fit into this power/complexity trade-off > nicely as the implementation of the ValAspect would be one or two senior > folks maintaining it, and still be usable by dozens of junior developers. I'm not sure you'd call it an aspect if it was adding support for 'val', but I know what you mean about one key group maintaining this kind of transform and another larger group simply consuming it. cheers Andy > On Thu, Aug 18, 2011 at 3:46 PM, Andy Clement <[email protected]> > wrote: >> >> Hi Steve, >> >> Someone else mentioned Lombok interop a little while ago. In >> *principal* it should be possible if AspectJ sorted out its support >> for annotation processing tools, I think, but so far I haven't had >> time to look at it. I got APT support working a while back for >> AspectJ but it was just in a prototype workspace that I've since >> misplaced. >> >> You are right that AspectJ could go down this road to some degree. >> I've thought about a few things, like >> auto-generating getters/setters (so not even requiring you to write >> ITDs, just being told in some way that this property needs a >> getter/setter and just creating them), supporting the null-safe >> dereference operator '?.' - and your val is kind of another case. >> Certainly goes beyond the initial remit of AspectJ as an aspect >> oriented programming language - but these are the kinds of things I >> think languages need these days. They need to cut down on the >> boilerplate and increase the productivity. >> >> I'd certainly welcome any opinions on this - I've not planned to do >> anything radical just yet. Moving AspectJ to rebase it on the Eclipse >> Java7 compiler will be keeping me busy. >> >> cheers >> Andy >> >> On 18 August 2011 07:42, Steve Ash <[email protected]> wrote: >> > I'm actually embarrassed sending this, because I feel like this is a >> > feature >> > request that is really unrelated conceptually to the goals of AspectJ -- >> > but >> > AspectJ is perfectly positioned (from a toolchain perspective) to be >> > able to >> > provide it. So I'm shamelessly abandoning my philosophical consistency >> > to >> > see if there has been any talk of this type of feature in the AspectJ >> > dev >> > community before: >> > >> > Any talk of being able to somehow use weaving to allow for a "val" >> > keyword >> > similar to scala, c#, or (now) Lambok? >> > >> > I realize that this is not really "weaving" but softening exceptions >> > isn't >> > really either -- and AspectJ supports that. Really I'm just having >> > feature >> > envy over those other tools and when Lambok demonstrated that they could >> > do >> > it just as an annotation processor (+ eclipse integration), then I'm >> > just >> > grasping for straws ready to use it. I don't want to mix Lambok and >> > AspectJ >> > as I've heard horror stories, and I'm not really anxious to adopt any >> > additional toolchain risk. >> > >> > Any thoughts in the community? >> > >> > Steve >> > >> > _______________________________________________ >> > aspectj-users mailing list >> > [email protected] >> > https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > >> > >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
