ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Re: PropertyHelper thoughts
Date Fri, 22 Jun 2007 17:22:26 GMT
On 6/22/07, Dominique Devienne <> wrote:
> On 6/22/07, Matt Benson <> wrote:
> > 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
> > 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.
> I'm sorry Matt, but I read your email carefully, and I'm not sure I
> got much out of it. Maybe it's doing C++ now that slows down my brain,
> but I'm not following. What's that IH connection you talk about? What
> string parsing?
> Right now, property references in attributes or text elements are
> expanded to strings (which I like ;-) and then IH does it's thing and
> converts that string to whatever type the task or type needs. Clear
> separation of concerns. Furthermore, these property "de-references"
> can be mixed with litteral text and/or other property "de-references",
> so if de-refing a property somehow returned an Object, that would
> force IH to somehow map an array of Strings and Objects to instantiate
> a type????
> Sorry to be so thick.. --DD

I am afraid that I also could not follow Matt's description, how does (or will)
PH interact with IH? and with resources ?

PH does in theory support objects as property values, however the api to use
to get and set properties is via Project, that it does not support objects as
property values.

I think that objects are supported already using references and we should
not support objects for properties (except for the null object).


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message