The fact that the meaning of <available> was overloaded in the past doesn't
mean we should continue doing so... And still, available currently looks for
files/streams (on file-system, classpath, path, etc...), which is quite
different than looking for particular characteristic of whatever's described
in these streams...

Condition names that could be used:
<classHasMethod>
<classHasField>
<classHasInnerClass>
<classIsAssigneableFrom>
etc...

Having separate conditions allows to associate them with <and>, <or>, etc...
as needed.

As far as allowing to check for particular method signature, when looking
for just the method name is not enough, then the simplest thing is to use
the JNI signature, as in "main([java.lang.String)V", and have an optional
modifiers attribute. This is well documented, and avoids having to parse the
signature as written in a Java source file. Of course if you really want the
ability to say "public static void main(String[])", you're welcome to write
the parser for it ;-)

--DD

> -----Original Message-----
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 15, 2003 1:49 PM
> To: Ant Developers List
> Subject: Re: Testing for an abstract method
> 
> Stefan Bodewig wrote:
> >>Any chance to get the <available> task a bit extended so
> >>that it can also be used to check for methods, fields,
> >>implemented interfaces etc. and specific properties...
>  >
> > Doesn't sound too hard.  I wouldn't augment available with it but
> > rather create a new condition, though.
> 
> Any suggestions for a name?
> What are the particular rationales to create a new condition
> rather than extending <available>? I thought that putting in
> declarations for further conditions would be a straightforward
> extension:
>   available class foo with
>         method foobar(int, int)
>     and protected static field bar (any type)
>     and implementing interface xyzzy
> 
> Hm, one problem is the syntax for
>    any method named bar
> and
>    method bar(void).
> People will probably assume that no declarations for
> parameter types mean the the latter and will wonder
> how to do the former. We can just omit the first case
> though.
> 
> J.Pietschmann

Reply via email to