Hi Martin,
I reconsidered your arguments for lexical separation, and I tend to think
that this might be a way to go during the transition period.
A/ allow it on lexical level:
So: if test=${some-long-property - long-function(1)=42}/ it means
prop - func(1)=42
but if test=${some-long-property-long-function(1)=42}/ it means
func(1)=42
1. There migth be quite a lot of production build scripts already written
which contain properties with dashes. We should support these for some time
while allowing the users to try expression evaluator.
2. No production expressions are written yet because EE has not been
released yet.
3. Let's (temporarily) allow property names defined as:
identifier { [dot|dash] identifier } *
but every time someone uses dash as a separator - we'll produce a big
warning saying it's deprecated and will be removed in future versions.
4. To avoid ambiguities one should use spaces to separate operands from the
MINUS operator.
With these rules in place, I think we'll be able to handle 99% of today's
build scripts. We'll still be failing on scripts that use numeric property
names or anything as weird as that.
Without it EE would break builds containing ${property-name-with-dashes},
which I'm sure, are there in the wild.
What do you think?
Can we merge EE-patches with main branch as soon as we have this semantics
implemented?
Jarek
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
