so
<property name="full.path" value="path.getfullpath('../../bar')" />
vs
<path property="full.path" partial="foo\bar\file.txt"/>
or
<path property="partial.path" fullpath="false" pathonly="true" partial="foo\bar\file.txt"/>
That leads me to another point. "Functional" tasks like this tend to have multiple "functions" combined in the one task to reduce the number of tasks that need to be written.
- hence your suggestion to split the path task it into 3 . The available task is the same - it really has 4 "functions" |File| |Directory|, |Framework| or |FrameworkSDK|. As a result these types of tasks have a tendancy to become unweildy as more attributes are added to encompass more functionality. Functions have the added advantage of composability ie
file.exists( path.getfullpath("foo\bar\file.txt") ). To do the same without functions would require the use of 2 tasks and the use of an intermediate property.
the regex task, availabletask and registry reading tasks fall into a similar category. For those tasks we can keep them around in parallell with the new functions and then we can take a user poll further down the road and see what peoples preferences are. I don't have a problem with keeping certain things as tasks as well as there corresponding functions- as long as the implementation is shared with the function version.
I don't think that anyone is suggesting the wholesale replacement of tasks with functions and in most cases you couldn't and shouldn't replace a task with an equivalent function.
Of course there will be cases where its not clear whether a given piece of functionality should be a task or a function. I don't believe that this is one of them - feel free to disagree with me.
Ian
Gert Driesen wrote:
<start-rant>
Guess this will be the start of many dilemma's ... I'm pretty sure there will always be people that prefer xml build elements only, and actually that's also one of my concerns ... I'd hate to see build files reduced to large chunks of scripts ...
As long as we allow build authors to choose themselves I certainly have no problem with the expression eval support, I actually like it very much, but we should give build authors a choice in this matter ...
I'm definitely not saying that we should provide a task alternative for every function we support in the expression eval, but by not providing task support for "basic" build "tasks", we're actually forcing build authors to use expression support ...
</end-rant>
If we decide to add William's task, I think we should : - add it to NAntContrib first - split it up into at least 3 tasks, like Ant has : dirname, basename, and path-combine (or something, doesn't exist in Ant)
What do you think ?
Gert
----- Original Message ----- From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "William E Caputo" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, December 14, 2003 5:38 AM
Subject: Re: [nant-dev] SUBMISSION: Path Task
This looks good William. However I'm thinking that the new function support will be easier to use to do this kind of stuff.
the following path related functions will be included:
path.changeextension path.combine path.getdirectoryname path.getextension path.getfilename path.getfilenamewithoutextension path.getfullpath path.getpathroot path.gettempfilename path.gettemppath path.hasextension path.ispathrooted
Ian
William E Caputo wrote:
(This is a resend. I didn't see it come across the list the first time I sent it. My apologies if it comes through twice)
Hi All,
Attached is a zip file containing a task called path. This task extracts path information from a given partial (or complete) path name and optionally expands it to a fully-qualified path, using either the current working directory or the Project's base directory as the root, and places in a designated property.
I looked through the list of tasks and didn't see anything that did something like this (and we needed it) so after implementing it in a script task, I decided to code it up as a full-fledged task and submit it in the hope that it will be useful to others.
I wrote it is as being in the Nant.Core namespace because that is where copy and mkdir are (and we seem to always be manipulating paths in our build files) but if the project's admins prefer that it be a somewhere else in NAnt or submitted to NAntContrib instead that is fine by me (I didn't cross post, but I will send it to that list if you like).
The task is accompanied by 12 tests, and is fully documented.
Best, Bill
William E. Caputo ThoughtWorks, Inc. http://www.williamcaputo.com -------- idia ktesis, koine chresis
Hi All,
Attached is a zip file containing a task called path. This task extracts path information from a given partial (or complete) path name and optionally expands it to a fully-qualified path, using either the current working directory or the Project's base directory as the root, and places in a designated property.
I looked through the list of tasks and didn't see anything that did something like this (and we needed it) so after implementing it in a script task, I decided to code it up as a full-fledged task and submit it in the hope that it will be useful to others.
I wrote it is as being in the Nant.Core namespace because that is where copy and mkdir are (and we seem to always be manipulating paths in our build files) but if the project's admins prefer that it be a somewhere else in NAnt or submitted to NAntContrib instead that is fine by me (I didn't cross post, but I will send it to that list if you like).
The task is accompanied by 12 tests, and is fully documented.
Best, Bill
William E. Caputo ThoughtWorks, Inc. http://www.williamcaputo.com -------- idia ktesis, koine chresis
------------------------------------------------------- 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
