I am all for this. Mangled names create problems with JPA and such. I guess one issue to consider is what happens when two aspects want to introduce a same-named field with a directive to not mangle, especially if both aspects are from third-party libraries. This is quite unlikely to occur in practice, but we may need to address it somehow. I wonder if the 'declare precedence' can be an arbitrator here.
-Ramnivas On Thu, Nov 19, 2009 at 10:54 AM, Andy Clement <andrew.clem...@gmail.com>wrote: > I'm possibly going to review our approach to intertype declaration > naming. The names are currently mangled deliberately to preserve some > of the 'rules' that AspectJ defines. For example, private field itds > have mangled names because the field is private to the aspect and > shouldn't be visible as a 'regular' private field in the target. This > also enables two aspects to ITD the same private field and there is no > clash in the target type. > > However, since those rules were defined a long time ago, things have > changed and various frameworks are looking at members via reflection, > for purposes of invocation or automatic persistence. The mangling is > unhelpful here. > > I *thinking* about allowing non-mangled names, possibly with a > directive annotation in the aspect that says "do not mangle these, I > know what I'm doing and there won't be a problem". > > Basically I wanted to collect any thoughts from you guys? > > I suspect that the some of the scenarios AspectJ worries about rarely > happen in practice - have you ever ITD'd the same named private field > from two aspects onto the same type? (AspectJ can continue to > warn/error when it sees this about to happen of course) > > cheers, > Andy > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users >
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
