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 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. Just some thoughts... Steve 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
