--- Peter Reilly <[EMAIL PROTECTED]> wrote:
> On 6/22/07, Dominique Devienne <[EMAIL PROTECTED]>
> wrote:
> > On 6/22/07, Stefan Bodewig <[EMAIL PROTECTED]>
> 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<String, String>, 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:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo!
FareChase.
http://farechase.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
