> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > Sent: Sunday, 16 December 2001 10:26 PM > To: Ant Developers List > Subject: Re: IntrospectionHelper questions > > > On Sun, 16 Dec 2001 22:34, Adam Murdoch wrote: > > Some questions about IntrospectionHelper and friends. > > > > - IntrospectionHelper arbitrarily chooses an attribute setter > method for a > > class when there is more than one of the same precedence. It silently > > ignores the others. Is there a reason for not failing, or at > least writing > > a warning? Any problems with me adding a warning? Is an > arbitrary choice > > of setter method really that useful? > > Well I haven't looked at the code but I was under the impression that it > would arbitarily choose a setter and ignore the rest. owever it > would try the > string setter if the other setter fails. > > The reason for this is essentially backwards compatability. We have a few > classes where something equivelent to the following is present > > public void setFoo( final String foo ) > { > setFoo( Project.toBoolean( foo ) ); > } > > public void setFoo( final boolean foo ) > { > _foo = foo; > } > > We need to keep the first method for backwards compatability > while the second > method is how it is supposed to be used. >
Yep - that bit was pretty clear. The behaviour when a String is involved is consistent - it will always choose the non-String one. My question was related to what happens when there's more than one non-String setter method. Ant will choose one of them, based on the order Class.getMethods() returns them (which, according to the Javadocs, is unspecified). > > - It looks like a refactor is overdue on the project > > parsing/construction/configuring side of things. With a bit of > a tidy up, > > it should be a fair bit easier to add new features (e.g. the polymorphic > > datatypes idea that was raised a while back), improve existing features > > (e.g. a lightweight <antcall>), conditionally switch on > experimental stuff > > (e.g. well, pretty much everything on the 1.9 action list), and > reuse (e.g. > > for, say, loading up task lib descriptors from an XML file - or > in Ant2). > > > > I realise, of course, that this stuff is the core of Ant, and that the > > whole backwards compatibility story depends heavily on it. So > the question > > is, would there be any support for doing this? Exactly what > "this" means, > > we can decide on later. I'm just trying to get a feel for what > is fixed in > > stone, and what is fair game for tidy-up. > > Well the API and the behaviour is largely set in stone. If you > can refactor > the insides to be cleaner then go for it - however because Ant > was originally > developed in a manner that makes it difficult to evolve (ie lots > of protected > attributes, plenty of public methods, side effects galore) it is > going to be > a tough job. Hmmm. Not sure I'll bother - it's the blurry bits between the API and the insides that I was most interested in tidying up. I guess the backwards compatibility rule means anything not strictly internal (private, say) can't be messed with too much. > > At the moment I am actually going through and refactoring this stuff in > preparation for Ant2 - but thats largely because we don't need to > maintain > any backwards compatability there. > No backwards compatability? Sounds fantastic. Need a hand? > -- > Cheers, > > Pete > > ------------------------------------------------- > "Sometimes its better to keep your mouth shut and > let people think your an idiot, than to open it > and remove all doubt." > ------------------------------------------------- > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
