ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: proposing
Date Wed, 28 Jun 2000 13:17:52 GMT
>>>>> "TO" == Tim O'Brien <> writes:

 TO> Will setFile( File ), be able to handle multiple files?

No, but setFile( could.

The basic idea is/was to allow attributes of any Object type that have
a constructor that takes exactly one String. 

File does fit this category in a way but the constructor doesn't do
the right thing, maybe use a home brewed version of File that does the
path resolution?

 TO> How would ProjectHelper know if the attribute contained a String
 TO> or a File?

It doesn't have to. If there is a setFile(File) method in task, assume
the attribute to be a File, if there is a setFile(Integer) assume it's
an Integer ...

 TO> Why not just stay with strings and let Task designers decide what
 TO> to do with property strings at set time?

If Task designers want to get the original string value, they will
have setFile(String) and no other method with the name setFile.

Just tell them that they could use setFile(File) instead and the
filename resolution would be done automatically - they still have all

 TO> Another function that there is already a need for is a
 TO> parseMultiple() function to resolve multiple string inputs.

I don't think I know where a method like this is needed. Which tasks
use multiple String inputs - or are you talking about tokenizing? My
feeling is that all attributes that are comma separated lists would
better be nested elements.


View raw message