On 2009-09-04, Dominique Devienne <ddevie...@gmail.com> wrote:
> On Fri, Sep 4, 2009 at 6:25 AM, <jan.mate...@rzf.fin-nrw.de> wrote:
>>> I suggest to add another core PropertyEvaluator that works like the one
>>> for toString but doesn't invoke toString() on the reference (but leaves
>>> that to IntrospectionHelper if necessary).
>>> The ${ref:} and ${refid:} ideas look prettier but are more likely to
>>> collide with existing property names.
>> Because you referencing an id I would prefer ${refid:*}.
> Tasks in the past had to explicitly support this by adding a separate
> attribute which typically (by convention) uses a "ref" suffix
> (classpath="...",
> classpathref="..."), so having the following two notations
> (classpathref="my_cp", classpath="${ref:my_cp}" equivalent leans
> towards using ref:.
That would only work if the setter inside the task would accept a Path
argument.
> We could avoid ambiguity by not using a ${} notation...
Ahh, that's what I wanted to keep for a different thread, but now that
you raise it ... see the thread I'm going to start next week ;-) [1]
> I'm not sure I like the fact that ${} would start returning something
> else than a String. Then there's classpath="foo${refid:my_cp}bar"...
> When you mix literals and a reference, what happens?
You get the same result that you'd get with
classpath="foo${toString:my_cp}bar" today - that's how it is
implemented, at least.
> BTW, we already have ${} and @{} which interact in interesting ways,
> allowing to do ${...@{bar}} inside a macro. How would #{} (or ${refid:})
> interact here?
If we hook it into the PropertyHelper mechanisms (what I suggested) it
will work just like any other property reference.
> Sorry to raise concerns again...
No reason to be sorry, that's why we discuss this stuff in the first
place.
Stefan
[1] OK, I'd like to provide a String => Resource mechanism, something
that has been discussed before. This is trivial for URLs, but we
need something more generic. If we wanted to plug it into the
PropertyHelper stuff (I haven't considered another option so far) it
would probably be easier if we used or own PropertyExpander in order
to allow something like #{url:${some.url}}.
There are still a few things that I haven't thought through, so I'd
like to defer that discussion for a few days, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
