I completely agree that what is in the last few years of readmes should be in the docs, but I just haven't had any cycles to do that work (as you recognize). The last time the docs had a big update was for AspectJ 1.5.
> I always thought that it was part of developer professionalism to do that. Yep, I'd really love to do it, and I do feel bad about it. But when it comes down to decisions like whether to have better docs or have Java8 support, I have to do the latter. I'm more than willing to take pull requests that do these doc updates if anyone has the time to help me. So if you are offering, go for it :) cheers, Andy On 22 July 2014 10:52, Alexander Kriegisch <alexan...@kriegisch.name> wrote: > I think that percflow(execution(...)) would not yield the desired result > because in between executions one would lose cache state. > > As for important information being scattered across README files per > release or even across Bugzilla tickets vs. making it a habit to update > documentation alongside releases, I want to recommend opting for the > latter. Sorry for requestion something without contributing, but I am a > mere user, not an AspectJ committer/maintainer. I do hope I am not > requesting too much even so. I always thought that it was part of developet > professionalism to do that. Probably development resources are being spread > on this project like too little butter on too much bread, so I see the > problem with my request. OTOH, most parts of the documentation seem not to > have been updated since AspectJ 5. (2005? I am unsure.) This situation > creates more work for developers on this mailing list, which is also > time-consuming. > > After having been such a smart-ass, I want to ask if there is any way I > can be of assistance. Andy? > -- > Alexander Kriegisch > > > Am 22.07.2014 um 19:06 schrieb Andy Clement <andrew.clem...@gmail.com>: > > In https://eclipse.org/aspectj/doc/released/README-164.html there is a > section on "Optimizing support for maintaining per join point state" which > talks about how to avoid using a map when you could use an array (using the > id number available from a join point). > > Just thinking in a hurry - maybe a percflow(execution(...)) might also be > possible, but I haven't thought that fully through. > > cheers, > Andy > > > On 22 July 2014 07:25, Alexander Kriegisch <alexan...@kriegisch.name> > wrote: > >> Hi Jon. >> >> I think there is no per-clause for distinct methods. I think your >> solution plus a Map, as you said, probably with keys generated from >> >> thisJoinPointStaticPart.getSignature().toLongString() >> >> or similar should do. Sorry for not having any better ideas than you by >> yourself. >> >> Regards >> -- >> Alexander Kriegisch >> http://scrum-master.de >> >> >> Jon Mann schrieb am 22.07.2014 15:54: >> >> > I have a simple aspect for caching the result of a method call. >> > >> > An annotation is used to mark a method which should be cached: >> > >> > public @interface CacheResult { } >> > >> > The aspect is implemented like this: >> > >> > @Aspect("perthis(targetMethod())") >> > public class CacheResultAspect { >> > >> > private Object result; >> > >> > @Pointcut("execution(@CacheResult * *.*())") >> > public void targetMethod() { } >> > >> > @Around("targetMethod()") >> > public Object aroundMethod(ProceedingJoinPoint thisJoinPoint) >> > throws Throwable { >> > if (result == null) { >> > result = thisJoinPoint.proceed(); >> > } >> > return result; >> > } >> > } >> > >> > This works great for target classes with only one @CacheResult method. >> > >> > But the problem is target classes which have multiple different >> > @CacheResult methods: >> > >> > class Target { >> > @CacheResult String method1() { return "method1"; } >> > @CacheResult String method2() { return "method2"; } >> > } >> > >> > Target target = new Target(); >> > target.method1(); // Caches and returns "method1" >> > target.method2(); // Returns cached "method1" but should >> > separately cache and return "method2" >> > >> > Currently, one instance of CacheResultAspect is created for each >> > instance of a target class, so the cache result is (incorrectly) shared >> > across all the @CacheResult methods of the target object. >> > >> > Is there a way to make AspectJ create a separate instance of >> > CacheResultAspect for each @CacheResult method in a target object? >> > >> > I could use a Map to work around this, but perhaps there is a better or >> > more performant solution? >> >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users >
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
