ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurdoch...@yahoo.com>
Subject RE: IntrospectionHelper questions
Date Sun, 16 Dec 2001 12:55:36 GMT


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> 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:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
> 


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