On Tue, Sep 1, 2009 at 7:08 AM, Matt Benson<gudnabr...@yahoo.com> wrote:
>> From: Stefan Bodewig <bode...@apache.org>
>> wanted to allow nested properties ${${foo}} since the default
>> PropertyExpander doesn't balance braces.
>
> Note that the props antlib does provide a NestedPropertyExpander, so you're
> right on track.
protected PropertyHelper() {
add(TO_STRING);
add(SKIP_DOUBLE_DOLLAR);
add(DEFAULT_EXPANDER);
}
What I don't get is how NestedPropertyExpander can be enabled.
Given how DEFAULT_EXPANDER works, if one tries to add
NestedPropertyExpander after it, the first expander will not allow
the second to work.
So one's supposed to extend PropertyHelper and do different adds?
Given that the 3 default expanders are private, one can't reuse them.
On a side note, I find it a bit non-symetrical to have PropertyExpander
in oata.property, while PropertyEvaluator & PropertySetter has nested
interfaces in PropertyHelper.
Finally, I'm not sure I understand PropertyExpander and its
ParseNextProperty arg. The interface gives me the impression that to
do nested property parsing, one must mix the parsing and evaluation
phases since parsePropertyName has to return a property name; thus
${foo${bar}} must evaluate ${bar} during parsing to be able to return
"foo1" if bar is "1".
I would have preferred the parsing to perform more akin to a compilation
phase, returning a little "program" (kinda like a little executable AST) which
is fully "un-evaluated", and can be evaluated fully given a particular execution
context.
Maybe that's useless in the context of Ant, where almost everything
happens dynamically at runtime, but it somehow bothers me that we
don't clearly separate parsing from evaluation. Just my $0.02. --DD
PS: Note that it's entirely possible I missed something. I had a quick
look only.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
