ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <ddevie...@gmail.com>
Subject Re: PropertyHelper thoughts
Date Fri, 22 Jun 2007 19:31:37 GMT
On 6/22/07, Matt Benson <gudnabrsam@yahoo.com> wrote:
> 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.

This use case I do care about. But I always felt refid handling should
be transparent to the tasks, and handled directly by the framework.
hard to retrofit on the current infrastructure though I think. But
where I'm getting at is that this particular example of yours, yes, I
agree it's a valid use case, but I don't think that the way to enable
it ;-)

I'm not overly fond of "special" handling in IH when the attribute
value is "entirely" a property  deref, but I could live with that is
others accept it. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message