Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 63097 invoked from network); 11 Apr 2005 18:53:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 Apr 2005 18:53:12 -0000 Received: (qmail 75498 invoked by uid 500); 11 Apr 2005 18:53:10 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 75465 invoked by uid 500); 11 Apr 2005 18:53:10 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 75448 invoked by uid 99); 11 Apr 2005 18:53:10 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from junior.lgc.com (HELO junior.lgc.com) (134.132.72.99) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 11 Apr 2005 11:53:08 -0700 Received: from lgchvw01.landmark.lgc.com (lgchvw01.lgc.com [134.132.93.107]) by junior.lgc.com (8.11.7/8.11.3) with SMTP id j3BIr9u04643 for ; Mon, 11 Apr 2005 13:53:09 -0500 (CDT) Received: from 134.132.72.99 by lgchvw01.landmark.lgc.com (InterScan E-Mail VirusWall NT); Mon, 11 Apr 2005 13:53:02 -0500 Received: from HOUEXCH903.landmark.lgc.com (houexch903 [134.132.167.43]) by junior.lgc.com (8.11.7/8.11.3) with ESMTP id j3BIr3N04611 for ; Mon, 11 Apr 2005 13:53:03 -0500 (CDT) Received: from HOUEXCH902.landmark.lgc.com ([134.132.167.38]) by HOUEXCH903.landmark.lgc.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 13:52:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: References Date: Mon, 11 Apr 2005 13:52:40 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: References Thread-Index: AcU+xbkv+UwUeBAtRlyjYjoCDXP8tQAANmvA From: "Dominique Devienne" To: "Ant Developers List" X-OriginalArrivalTime: 11 Apr 2005 18:52:51.0234 (UTC) FILETIME=[A974B820:01C53EC7] X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N > From: Matt Benson [mailto:gudnabrsam@yahoo.com] >=20 > 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.=20 True. > 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. But assuming that the framework starts unconditionally handling datatype refids, then older code keeps on working just fine. The old setRefid() methods never get called (by the framework), and the manual checks succeed, while still catching erroneous programmatic use of setRefid(). New types just ignore refid altogether, and are greatly simplified. So on second thought, it sounds doable. The only possible break of BC I can foresee ATM would be for custom types, outside of Ant, which broke the unwritten rule that no attributes/elements are allowed once one uses refdid=3D"someId", and I don't mind that ;-) --DD --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org