ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: IntrospectionHelper questions
Date Sun, 16 Dec 2001 12:25:38 GMT
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.

> - 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.

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.



"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:   <>
For additional commands, e-mail: <>

View raw message