> By adding expression support we are moving functionality from the tasks > (defined by xml) to the expression engine. Now I am starting to think about > how to add support for extensions to the expression engine; just like I > think about how to add functionality by creating new tasks. This is the > slippery slope that I think we need to be careful about.
I think that there's a clear distinction: expressions are "pure". They don't have side effects. They don't change state - neither the program memory nor property space, filesystem, registry, databases. They only return values based on current state. Tasks actually do things and may change state. Currently we have tasks that do nothing but set some properties so that other tasks could decide upon them. I believe this should be the first (and probably the last) target. But, I agree that this is a slippery matter. > Really I just want to make sure we get the feedback, user comments, and > support we need for adding this feature. Maybe the next step after we > discuss this on the dev list is to get together another summary email for > the user list. Then we can make a final decision about if we want to add > this new feature to a release. This is probably the most difficult task. I don't know how many people are there on the dev list, but "test1" release was downloaded by only 16 persons (distinct IP addresses) and we only got opinions from 4 (not counting myself). I think that in order to get most people to test EE we should: 1. Formally define property names (this will break some builds, but is necessary anyway) 2. Agree on expression syntax (as I understand it - Scott, Ian, Gert, Martin and myself agree on Q1/A). Q2 is open, but we're close to option A. 3. Provide user documentation and unit tests. 4. As soon as we're sure that EE doesn't break builds, we should move it to the main branch in CVS so that more people could test it via daily builds. There should be a command line/config option to turn it off (revert to the old behaviour) in case it causes any trouble. 5. If there's no common demand for expressions or if it breaks too many builds - we'll remove it (it's a single change in one file). Perhaps it could be then moved to a new task, called <eval expression="..." property="..." /> What do you think? 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
