Re: [nant-dev] SUMMARY: Expression Syntax

Sun, 07 Dec 2003 19:44:45 -0800

I have to agree with Jarek on this. If we *don't* add EE support then we'll continue adding more nested element types to construct the poor mans expressions that we have now. For me expressions are much simpler than using multiple nested elements to accomplish the same thing. I don't feel that functions add undue complexity to xslt although thats probably not the best comparism - it would be almost impossible to write a meaningful transform in xslt without fucntions.

We have a seperate branch for this stuff and I think we can keep it there until its stable - ie get people to test builds off that branch before we merge it back into the head.

btw I'm about half way thru implementing support for custom user defined functions. Its really just an extension of the current task, type scanning via reflection that we do already.

Ian


Scott Hernandez wrote:

Good point about side-effects. This does paint a clear distinction. But then
you get tasks like xmlpoke, with no corresponding xmlpeek; this might make
the user search around for the expression/function to use, or even assume
that this functionality does not exist.

I'm inclined to give this a day or two to stew, commit the changes to the
head, if there are no serious issues. We doc, write unit tests, and do a
release with expression support in a week or less. Then we can provide this
release to the users and get feedback. If people are up in arms about it
breaking builds, we can pull it (removed the feature from the head, and put
them back in the ee branch). We are still in pre-1.0 releases and changes
are acceptable. The sooner we get this issue resolved, the sooner we can get
to a 1.0 release.

We can also put a switch in our config section, and a command line option,
to turn it off, as you have suggested.

Does that sound like a plan? ( I guess I'm just restating your plan
Jaroslaw, but with a little bit of timing :)

----- Original Message ----- From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>


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




--
Ian MacLean, Developer, ActiveState, a division of Sophos
http://www.ActiveState.com




-------------------------------------------------------
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

Reply via email to