Hi Andy, As someone who has made a lot of use of ITDs, including aspect libraries that I use on multiple projects, I don't see many scenarios where a name clash would occur, and on the rare occasion where it did happen I would have no problem refactoring. Just my two cents.
Dave Whittaker Iradix, LLC (p) 212.513.0874 x100 (f) 212.504.8213 [email protected] On Thu, Jan 21, 2010 at 4:10 PM, Olle Hallin <[email protected]> wrote: > But do people really know (or care) what ITDs aspect libraries contain? > Or are pehaps aspect libraries not used very much? > > Olle > > Olle Hallin > Senior Java Developer and Architect > [email protected] > www.crisp.se > http://www.linkedin.com/in/ollehallin > > > > 2010/1/21 Andy Clement <[email protected]> > > 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 >> > > > _______________________________________________ > 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
