On Sun, 21 Jan 2007, Andy Levy wrote:
> On 1/17/07, Daniel Rall <firstname.lastname@example.org> wrote:
> >> >o Special-case wsf files on Windows to run them using cscript.exe
> >> (warning: slippery slope & scope creep ahead!)
> >> If this is the chosen solution, would it be reasonable to use WSH's
> >> named arguments for passing the arguments into the script? Instead of
> >> addressing each parameter by the order in which they're specified on
> >> the command line, one could address the parameters by name.
> >Could you provide an example of this?
> Basically it's WSF's version of getopts, if I understand getopts right.
> Simple example.
> Let's say I have a wsf script which copies the contents of one
> directory to another directory, and it's set up to expect the source
> as the first parameter, and the second as the destination.
> So, I do this:
> cscript.exe copyfiles.wsf c:\source c:\destination
> var sourceDir = WScript.Arguments.Unnamed(0);
> var destDir = WScript.Arguments.Unnamed(1);
> However, if I set my script up for named variables, I'll do this:
> cscript.exe copyfiles.wsf //dest:"c:\destination" //source:"c:\source"
> var sourceDir = WScript.Arguments.Named.Item("source");
> var destDir = WScript.Arguments.Named.Item("dest");
> Now that I'm using named variables, the order they're passed on the
> command line no longer matters, because the script host looks for the
> parameters by name, not position. It also helps things self-document a
> little better (my opinion).
> One can mix named and unnamed arguments, but my preference is to name
> them all, or name none.
While I am in agreement that this presents a much cleaner API, we're
unlikely to do so because it special-cases the hook script API for WSF
files. Special-casing the implementation is bad enough, but at least
it doesn't require lots of extra documentation. :)
Received on Tue Jan 23 00:42:06 2007
- application/pgp-signature attachment: stored