--- 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?
>
Okay, RuntimeConfigurable performs property
replacement on attribute strings and calls
IH.setAttribute with the substituted string. PH uses
a basic set of parsing rules: ignore $$, ${ marks the
beginning of a property, the next encountered } marks
the end. Because we know that nested property
evaluation is a highly requested property-related
capability, it becomes easy to see that the parsing
approach to use is a natural extension of property
handling. The related interface is PropertyExpander.
If the entire content of a string, e.g. "${src.dir}"
is a property, you can see there is a difference
between this type of attribute value as opposed to
"text ${property} text".
Let me divert the topic for a moment--the other of the
two most important property handling extension points
can be expressed with a PropertyEvaluator interface.
A perfect example is Ant's built-in toString:refid
property "syntax". Basically that's an example of a
custom PropertyEvaluator that interprets a string
beginning with "toString:". Now imagine a
complementary custom property evaluator that evaluates
"refid:refid" to the Object reference. Overload
IH.setAttribute to allow Object values. Change
property replacement such that a string whose entire
contents are a property that evaluates to an Object,
returns the Object. With the postulated refid:refid
PropertyEvaluator, "${refid:myclasspath}" would return
the Path at refid myclasspath. If RuntimeConfigurable
calls the PH method that is capable of returning an
Object, then passes that Object (or String) to the
overloaded IH.setAttribute(), we have just rendered
all classpathref attributes obsolete; rather, any task
can support ref'd types in attributes without having
to support the foo|fooref paradigm. If the attribute
isn't settable as the returned Object, convert the
Object to a String and pass it to the original
IH.setAttribute() implementation.
>From all this it actually becomes evident that the
parsing mechanisms are, or should be, secondary to
this issue. :)
> 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????
>
Hopefully from my examples above you can see that I'm
not suggesting anything as... weird, for lack of a
better word, as that. :)
-Matt
> Sorry to be so thick.. --DD
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for
today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
