Return-Path: 
 <dev-return-65815-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 59220 invoked from network); 11 Apr 2005 18:39:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 11 Apr 2005 18:39:03 -0000
Received: (qmail 50790 invoked by uid 500); 11 Apr 2005 18:38:47 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 50707 invoked by uid 500); 11 Apr 2005 18:38:47 -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 50641 invoked by uid 99); 11 Apr 2005 18:38:47 -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 web30905.mail.mud.yahoo.com (HELO web30905.mail.mud.yahoo.com)
 (68.142.200.158)
  by apache.org (qpsmtpd/0.28) with SMTP; Mon, 11 Apr 2005 11:38:45 -0700
Received: (qmail 91730 invoked by uid 60001); 11 Apr 2005 18:38:43 -0000
Message-ID: <20050411183842.91724.qmail@web30905.mail.mud.yahoo.com>
Received: from [65.247.233.95] by web30905.mail.mud.yahoo.com via HTTP;
 Mon, 11 Apr 2005 11:38:42 PDT
Date: Mon, 11 Apr 2005 11:38:42 -0700 (PDT)
From: Matt Benson <gudnabrsam@yahoo.com>
Subject: RE: References
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

Hmm, from all your comments it seems you have pointed
out that the best solution would be for types to have
no knowledge whatsoever of refids.  Of course this is
not possible under the gaze of the BC monster.  We
could always start the mythological Ant 2 after 1.7 to
apply the learning of the past several years.  I'll
keep thinking about this, though.

-Matt

--- Dominique Devienne <DDevienne@lgc.com> wrote:
> > From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> > 
> > Ever noticed that every Ant type that supports the
> > id/refid pattern must include a load of custom
> code?
> > Why?  Wouldn't it be possible in UE to check all
> > DataType subclass elements for refid, validate no
> > other attributes/elements/nested text, and
> substitute
> > the actual object?  It doesn't appear that
> DataType
> > supports Locations so that wouldn't be an issue. 
> Who
> > can point out any flaws in this approach?
> 
> That's how it should have been in the first place
> ;-)
> 
> Would you change the data types' code to remove the
> checks
> and setRefid() methods? If not (for obvious BC
> reasons), then
> what should be the behavior between the old and new
> way to
> deal with refid?
> 
> Also, the old "in code manual checks" of dealing
> with refid
> works even programmatically (like in <script>), when
> the new
> one works only thru the framework. For new DataType
> without
> a setRefid() method, that's not an issue, but for
> older code
> I don't know how to handle it. --DD 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 


		
__________________________________ 
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