ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: API changes introduced while fixing bug 10755
Date Tue, 11 Feb 2003 21:47:51 GMT
At 06:33 AM 2/11/2003, Stefan Bodewig wrote:
>On Fri, 07 Feb 2003, Bruce Atherton <bruce@callenish.com> wrote:
> > If the comment at the top of the file is a true indication of what
> > it is for, then how about "ResourceProcessingUtils", or perhaps more
> > simply "ResourceUtils".
>
>s/process/select/ in the comment.  What about the name then?

This is in large part a conversation about the colour of a bikeshed, but 
since you ask...

We seem to have a loosely adhered to policy of calling a class that 
provides static methods xxxUtils, so even though this is in the utils 
directory I think it is a good idea to include that suffix.

For better or worse, the term "selector" has a meaning in Ant, and I'm not 
a big fan of overloading meanings if we don't have to. With the 
substitution in the comment, perhaps ResourceSelectionUtils would be a 
better name (although still potentially confusing). ResourceUtils would 
still work, too, making this class the resource for all static utility 
methods that work with resources.

OTOH, perhaps the methods in SelectorUtils fit within the contract of 
SourceSelector and should be folded into it, perhaps with a broadening of 
the types of parameters that are accepted. Eventually we'd like a future 
where Scanners can be used interchangeably in all tasks, no? You could 
declare the class is for all utility methods that support filtering a 
collection of resources. Even then, I'd go with a name like 
ResourceSelectorUtils or something similar. "Source" is misleading in the 
name of this class, I think.


> > Is it necessary that Scanners call the logging API?
>
>Not really.  System.err would probably work.  The problem are debug
>messages that you normally would want to suppress, we can as well drop
>them.

Regarding System.err, that seems unnecessary to me if you are willing to 
throw BuildExceptions (unless I'm missing something). If the current code 
prohibits declaring BuildException in the method signature and you aren't 
willing to use exceptions without compile-time checks (you can always 
document them in the Javadoc), then logging probably is a better solution 
than System.err even if it complicates the API. It gives more control to 
our logging infrastructure.

As for debug messages, the question is whether you need access to the 
Scanner internals for debugging, or if all you need is information about 
the external behaviour (which can be logged at a higher level in the 
program). The tradeoff is between getting more details about low level 
operations and having looser coupling between these low level pieces and 
the rest of the system. My inclination is for looser coupling unless people 
developing custom tasks are likely to need those details. Just a 
preference, though.

So my thinking (and what I did in Selectors) is to avoid logging anything 
at that level, provide methods if necessary that allow referees to get 
information for debug messages if they need it (eg. toString), and throw 
BuildExceptions with abandon.

Just my POV.



Mime
View raw message