Return-Path: 
 <ant-dev-return-24078-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 59909 invoked from network); 30 Jan 2002 10:52:09 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 30 Jan 2002 10:52:09 -0000
Received: (qmail 8402 invoked by uid 97); 30 Jan 2002 10:52:18 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 8385 invoked by uid 97); 30 Jan 2002 10:52:18 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 8373 invoked from network); 30 Jan 2002 10:52:17 -0000
X-Authentication-Warning: bodewig.bost.de: bodewig set sender to
 bodewig@apache.org using -f
To: ant-dev@jakarta.apache.org
Subject: Re: Task postfix?
References: <200201300830.g0U8Up406930@mail012.syd.optusnet.com.au>
From: Stefan Bodewig <bodewig@apache.org>
Date: 30 Jan 2002 11:40:03 +0100
In-Reply-To: <200201300830.g0U8Up406930@mail012.syd.optusnet.com.au>
Message-ID: <m3u1t4f7gc.fsf@bodewig.bost.de>
Lines: 26
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Wed, 30 Jan 2002, Peter Donald <peter@apache.org> wrote:

> I vaguely recall someone advocating that we post fix all our tasks
> with "Task" (was that you Erik?).

Why?

ExecuteOn.java used to implement <execon> (something you could guess
by then) and we later renamed that task as <apply> - so people have to
look up which class implements <apply>, they cannot guess it.

Using above rule, the class would have been ExecOnTask - how would
that improve the situation?  Same for CallTarget.java that would
be CallTargetTask, not AntCallTask ;-)

Maybe it would be better to not place any classes into the taskdefs
package that are not implementations of tasks but utility classes?

> any objections or not?

Other than "I don't like it"?  No. 

But I don't like pre/post-fixing my variable names either and do so in
environments where I have to.

Stefan

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>