I see, so we are already talking about entirely different mechanisms... this is definetly not something to rush. I was imagining a construct similar to a field ITD that removed the named field rather than adding it, but you are talking about some variant of advice for this. A kind of field set/get joinpoint around advice where the field is removed as part of being advised, sounds a bit scary. Definetly needs more thought. I wonder if any readers of the list from academia have spent time thinking about using AOP for removal of program pieces? (anyone?)
This is why I went ahead with annotation removal, it is much more simple. cheers Andy On 24 June 2011 09:21, John Patterson <[email protected]> wrote: > Hi Andy, I simplistically imagined that the advice that replaced the field > would need to handle "getfield" and "setfield" (if it was not final) so > anything in the class that previously accessed that private field would call > the advice code instead. Kind of like in Eclipse when you refactor a field > to be encapsulated with a getter and setter. > > On 24/06/2011 22:53, Andy Clement wrote: >> >> Hi, >> >> Removing annotations was the first time we'd explored any kind of >> removal of something from a type. I'm nervous about going further, >> even with something like fields it would be very easy to leave a class >> in a state where other types that depend upon on it are then broken. I >> guess if it was scoped down to private fields and you couldn't do it >> if we determined any code in that type was using the field, we could >> do something. But that kind of code (detecting if the field is used >> somewhere) is not something we already have so would need writing and >> integrating into the weaver pipeline. Would these kinds of fields >> have getters/setters - what would happen to those? If only used in a >> getter/setter is it still safe to remove, if the getters/setters are >> also removed we're back to the case of leaving other code that depends >> on us in a broken state. I just think there are a lot of things to >> think through for a general solution. >> >> cheers >> Andy >> >> On 23 June 2011 19:46, John Patterson<[email protected]> wrote: >>> >>> Hi, I read that the recent 1.6.11 release adds the ability to remove >>> annotations and was wondering if the ability to remove fields was also >>> likely to be added. >>> http://code.google.com/p/salve/wiki/WhyNotAspectJ >>> This brilliant library seems a little hamstrung without the ability to >>> replace dependency fields. >>> Cheers, >>> John >>> _______________________________________________ >>> 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
