Re: [aspectj-users] Intertype declaration name mangling - for or against?
I'm wondering, is it interesting that I proposed it because it seems
like it would cause me problems with all the ITDs I use, or because it
just seems problematic in general? I think in my personal use cases I
have ITDs with very specific behavior which is unlikely to cause many
name clashes, and since they are private fields if name clashes were
to occur re-factoring the the code would be rather simple. I did
think of one potential problem though. Lets say I have an ITD that
handles object selection.
public interface SelectAction{
public void select(Object selected);
}
public aspect SelectActionAspect{
public Object SelectAction.selected;
public void SelectActoin.select(Object selected){
this.selected = selected;
}
}
Pretty straight forward stuff, an interface and a default
implementation. Now, I'm not worried that I might have a second ITD
that would also inject a field named selected, but what if that
default behavior didn't work for me and I wanted to do something to
the object when it is selected. What happens if I do:
public class SelectImpl implements SelectAction{
private Object selected;
public void select(Object selected){
System.out.println(I'm selected + selected);
this.selected = selected;
}
}
What happens there? Do I get an error that I can't add a field with
that name, which would be bad because I might need to have a field
named selected available for introspection? Does the implementation
field take precedence? What then happens if I have a second method in
my ITD that accesses the injected field? Does that method now refer
to the new overridden field? I think maybe it makes the most sense
that if a conflict like that arose the ITD wouldn't be applied at all,
but that would have to be very obvious to the user in order to avoid a
lot of confusion. Maybe an annotation could be added that allowed one
to selectively turn off ITDs for a particular type and the compiler
would raise an error on a field name conflict unless that annotation
was used:
public class SelectImpl implements @ApplyITD(false) SelectedAction{
...
}
Just some thoughts
On Nov 20, 2009, at 2:12 PM, Andy Clement wrote:
Thanks Dave and Ramnivas. yes I have progressed on the new intertype
syntax, but a mountain of testing to do there. It is interesting
about you (Dave) proposing the default be switched to non-mangling -
I'm nervous about that (from a backwards compatibility point of view I
think), but not entirely against it. Intertype fields are far far far
far more straightforward than intertype methods, so that's where I'd
play around first and that would seem to help a lot with these
frameworks.
Andy
2009/11/20 Ramnivas Laddad ramni...@aspectivity.com:
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
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Intertype declaration name mangling - for or against?
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.comwrote: 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
Re: [aspectj-users] Intertype declaration name mangling - for or against?
Thanks Dave and Ramnivas. yes I have progressed on the new intertype syntax, but a mountain of testing to do there. It is interesting about you (Dave) proposing the default be switched to non-mangling - I'm nervous about that (from a backwards compatibility point of view I think), but not entirely against it. Intertype fields are far far far far more straightforward than intertype methods, so that's where I'd play around first and that would seem to help a lot with these frameworks. Andy 2009/11/20 Ramnivas Laddad ramni...@aspectivity.com: 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 ___ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Intertype declaration name mangling - for or against?
Andy,
I'm all for this. It's something that I've thought about requesting
in the past but since I have some other ITD features that I'm slightly
more interested in like the new ITD syntax (I noticed the update to
the bug today, good stuff) and the ability to invoke super.method()
when overriding a method introduced via ITD, I figured it could
wait . Anyway, I think this absolutely would help ITDs work in a more
seamless manner with various frameworks that do a lot of reflection
(JPA, Seam, Spring, etc). It would be fine whether this was done by
annotation (possibly something like: @Asis intertype
ITDInterface{ } ?) or it became the default (maybe turned of via an
annotation?).
On Nov 19, 2009, at 1:54 PM, Andy Clement 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
Re: [aspectj-users] Intertype declaration name mangling - for or against?
Hi Andy, You mentioned that the annotation directive might be placed on the aspect itself. Would it not be better to control the name mangling through config passed to the weaver? The reason I mention this is because often the developer of the aspect is not the end user and only the end user can know if this is a safe operation. Jeff - Reply message - From: Andy Clement andrew.clem...@gmail.com Date: Thu, Nov 19, 2009 18:54 Subject: [aspectj-users] Intertype declaration name mangling - for or against? To: aspectj-users@eclipse.org 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
