On 6/22/07, Dominique Devienne <[EMAIL PROTECTED]> wrote:
On 6/22/07, Matt Benson <[EMAIL PROTECTED]> 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
> 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.
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).
Peter
---------------------------------------------------------------------
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]
