Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 58293 invoked from network); 22 Jun 2007 15:47:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Jun 2007 15:47:29 -0000 Received: (qmail 22287 invoked by uid 500); 22 Jun 2007 15:47:31 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 22253 invoked by uid 500); 22 Jun 2007 15:47:31 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 22238 invoked by uid 99); 22 Jun 2007 15:47:31 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2007 08:47:31 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [206.190.58.164] (HELO web55115.mail.re4.yahoo.com) (206.190.58.164) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 22 Jun 2007 08:47:27 -0700 Received: (qmail 3672 invoked by uid 60001); 22 Jun 2007 15:47:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=FVfAGuDlgFzbAYpydnQ7mALOC/sJ5Uw04cLtuLUNEbK9Hu0VDlCRdbSmsoPQnsoCbcRZSo6M3QZvWNi0aVA0Ow5rPDGVTMcpEqhqJbAP3KdMiRRO5ucupCuIe7nYqA8NdBX2dyer8PXDX/eQvQrwoh9Pe5Om5dVhsFXG9qk/OOU=; X-YMail-OSG: z2QqdnQVM1lAJ4YRGiU7ozJTnoUxm5jILt1TCWdTW_EP17z5yNyh_k4.hHf7d1G0Bebc9JV7gXxX9zTvAhnj1_Wzode2IFhC.ZxkLhBShs9_t.jAA52imMsb.Duu8LnxHPUSnl57jHM.ayQ- Received: from [67.142.130.37] by web55115.mail.re4.yahoo.com via HTTP; Fri, 22 Jun 2007 08:47:05 PDT Date: Fri, 22 Jun 2007 08:47:05 -0700 (PDT) From: Matt Benson Subject: Re: PropertyHelper thoughts To: Ant Developers List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <752135.3250.qm@web55115.mail.re4.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org --- Peter Reilly wrote: > On 6/22/07, Dominique Devienne > wrote: > > On 6/22/07, Stefan Bodewig > wrote: > > > > Funnily enough I did restrict Properties to > Strings > > > > and all the tests passed. :) > > > > > > You mean I didn't write a unit test when I fixed > Bugzilla Issue 904? > > > OK, what can I say? hmm, trying to come up with > a cheap excuse, March > > > 2001, ah yes, Ant 2 and all that. I must have > been too busy with > > > politics. > > > > > > Actually your change would be totally unrelated > to the bug in question > > > which involved Ant assuming that System > properties were all strings > > > when copying them over to the Ant properties. > > > > Did I say that I want Ant properties to be Strings > only? > > > > For System properties which are not Strings, they > could be either (1) > > ignored, with a warning or not, and (2) pushed in > the reference map > > instead (which a warning or not). > They should be ignored. > The Property javadoc page explicitly says that is it > incorrect > to use the underlying data structure directly . > """ > Because Properties inherits from Hashtable, the put > and putAll > methods can be applied to a Properties object. Their > use is strongly > discouraged > """ > > > > But for Ant properties, they should *always* be > Strings!!! ;-) --DD Can we keep this discussion afloat? I've done a lot of thinking on this issue over the past week and a few days ago I had the epiphany that an Object-enabled PropertyHelper is legitimate if we think of the "Property" part of the name as having a double meaning: yes, it manages a Projects Properties-as-in-Hashtable, but it could be made to assist the IntrospectionHelper further if it can be configured with delegates who know how to generate an object from a notation. Can you see it coming? We've arrived at my other pet issue: decoding a Resource from a String. Change the behavior of replaceProperties such that a string which begins with a property and is completely consumed after that property has been parsed returns the object directly. If some delegate returned e.g. a Resource, the IH would first try to assign that directly before reverting to its existing String configuration behavior. Once I made this realization I looked back at Costin's comments and saw this was exactly where he was headed. Bearing all the above in mind, it seems useful at the very least for property retrieval and string parsing (related but separate concerns) to have the potential to return an Object. Given this, the concern over System.properties having Objects shoved in, and the momentum of PropertyHelper having at least theoretically supported Object properties for all this time, I don't think there's much reason to stop Object properties cold, even if we vocally discourage their use. -Matt > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > dev-unsubscribe@ant.apache.org > > For additional commands, e-mail: > dev-help@ant.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > dev-unsubscribe@ant.apache.org > For additional commands, e-mail: > dev-help@ant.apache.org > > ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org