On Sun, 21 Jan 2007, Andy Levy wrote:
> On 1/17/07, Daniel Rall <dlr@collab.net> 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
>
> and in the wsf (I use JavaScript in my WSH scripts), I have:
>
> 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. :)
- application/pgp-signature attachment: stored
Received on Tue Jan 23 00:42:06 2007