ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
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.

-- 
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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message