Return-Path: Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Delivered-To: mailing list dev@ant.apache.org Received: (qmail 46723 invoked from network); 11 Feb 2003 21:47:55 -0000 Received: from avuemail.avuetech.com (12.18.183.75) by daedalus.apache.org with SMTP; 11 Feb 2003 21:47:55 -0000 Message-Id: <5.2.0.9.0.20030211123639.03957288@orson.callenish.com> Date: Tue, 11 Feb 2003 13:47:51 -0800 To: "Ant Developers List" From: Bruce Atherton Subject: Re: API changes introduced while fixing bug 10755 In-Reply-To: References: <5.2.0.9.0.20030207155528.03055a60@orson.callenish.com> <5.2.0.9.0.20030207155528.03055a60@orson.callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 06:33 AM 2/11/2003, Stefan Bodewig wrote: >On Fri, 07 Feb 2003, Bruce Atherton 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.