Return-Path: 
 <dev-return-65975-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 10722 invoked from network); 15 Apr 2005 21:21:50 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 15 Apr 2005 21:21:50 -0000
Received: (qmail 47295 invoked by uid 500); 15 Apr 2005 21:21:48 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 47254 invoked by uid 500); 15 Apr 2005 21:21:48 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 47236 invoked by uid 99); 15 Apr 2005 21:21:48 -0000
X-ASF-Spam-Status: No, hits=2.5 required=10.0
	tests=DNS_FROM_RFC_ABUSE,FORGED_YAHOO_RCVD
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from web30903.mail.mud.yahoo.com (HELO web30903.mail.mud.yahoo.com)
 (68.142.200.156)
  by apache.org (qpsmtpd/0.28) with SMTP; Fri, 15 Apr 2005 14:21:47 -0700
Received: (qmail 8453 invoked by uid 60001); 15 Apr 2005 21:21:45 -0000
Message-ID: <20050415212145.8451.qmail@web30903.mail.mud.yahoo.com>
Received: from [65.247.233.201] by web30903.mail.mud.yahoo.com via HTTP;
 Fri, 15 Apr 2005 14:21:45 PDT
Date: Fri, 15 Apr 2005 14:21:45 -0700 (PDT)
From: Matt Benson <gudnabrsam@yahoo.com>
Subject: RE: ResourceCollections
To: Ant Developers List <dev@ant.apache.org>
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

--- Dominique Devienne <DDevienne@lgc.com> wrote:
> Martijn, Matt, the example above would be necessary
> if and only
> if <resourcecollection> only had a
> add(ResourceSelector). In
> practice, we'll likely have specialized
> addAnd(ResourceSelector) and co
> so that if can be written just:

oh, that's partly what I was trying to avoid.  Part of
the beauty, to me, of some of the latest introspection
code is the ability to use add() methods.  It makes me
unhappy to have to specify element names in my
configuration methods where there is no ambiguity. 
For example, if you have to add multiple elements of
the same type to be used for different purposes, then
okay, how else would you know which was which?  But in
the case of the <restrict> ResourceCollection (which
is the context for ResourceSelectors), why should I
have to support addAnd(), addOr(), addNot(),
addNone(), addMajority, etc., etc., when I could code
add(ResourceSelector) and be done with it?  That takes
us back to either forcing the explicit declaration at
all times or trying to code something that uses
context to decide which "and" the user means at
runtime... fine, but also complicated and, as Peter
pointed out, bound to encounter ambiguity errors.

[trying to snip as much as possible lest these become
unmanageable]

-Matt


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/

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