Hi Olle, yes, that is the main option I am considering (as it is minimal effort on my part) but I mainly posted to know how much pain a change like this would cause as this is something that always 'just works' with the existing strategy. If enough users complained that it would affect them, I would try come up with a more sophisticated solution, but so far no-one seems to mind. So far I've only ever seen this come up with AspectJ test programs that are deliberately trying to do it, I don't have a real world scenario that demonstrates the need for it.
cheers, Andy 2010/1/21 Olle Hallin <[email protected]>: > Why not let transparent weaving be default, with compile error for name > clashes? > If someone (perhaps much later) writes a second ITD (or uses a third-party > aspect) that causes a name clash, only then the transparent weaving must be > disabled. > Olle Hallin > Senior Java Developer and Architect > [email protected] > www.crisp.se > http://www.linkedin.com/in/ollehallin > > > 2010/1/20 Andy Clement <[email protected]> >> >> I'm currently looking at transparent weaving, this is where the >> resultant bytecode looks more like the user might guess it would based >> on their declarations. Consider: >> >> class Foo { >> } >> >> aspect Bar { >> private int Foo.i >> } >> >> Compiling that will not give field 'i' on Foo *if* you look at >> Foo.class through javap. Instead it will be a mangled name. I would >> like to preserve the name but it leaves me with this problem: >> >> class Foo { } >> >> aspect BarOne { >> private int Foo.i >> } >> >> aspect BarTwo { >> private int Foo.i >> } >> >> which, with the 'old style' of ITDs will work fine as the mangled >> names won't clash. In a transparent weaving world I'm trying to >> decide the best way to handle it, so I thought I'd ask here if anyone >> is actually doing it? >> The options would seem to be: >> - make it a compile error to do it (seems a shame when it could be done >> before) >> - one of them gets the name 'i' and the other gets a mangled name. >> Possible but a lot of implementation work. >> - make transparent weaving an option and not the default mode, so a >> user has to request it at compile time. (I'd rather avoid this if I >> can and have transparent be the default) >> >> Remember, there is no change here to ITD semantics, purely in how they >> are represented in the resultant bytecode. So - do you ever ITD the >> same named field onto a type from two different aspects? >> >> thanks, >> Andy >> _______________________________________________ >> 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
