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