Before you can use Exists or any other WshNamed method or property, you need to retrieve the WshNamed collection. To do so, you use the WshArguments' Named property. If the caller didn't specify any named arguments on the command line, the Named property returns an empty collection.
To retrieve a named argument in WshNamed, you use the Item property. You use WshNamed's Item property in a slightly different way than I used WshArguments' Item property earlier. With WshNamed's Item property, you don't use a 0-based index but rather a string that evaluates to the argument's name, as the code at callout A in Listing 2 shows. This code retrieves the value of the named argument called server. Notice that the argument's name doesn't include the leading slash or the trailing colon. You don't use these characters when working with a named argument in a script; you use them only when you enter a named argument on the command line. Also notice that the code doesn't include the Item property. Like WshArguments' Item property, WshNamed's Item property is the default, so you can omit it in VBScript code.
If you don't know the names of the arguments in WshNamed, you can take advantage of the code that Listing 3 shows. This code iterates through the collection and displays the name and value of each argument.
A Quantum Leap
The introduction of named arguments in WSH 5.6 is a quantum leap from the previous versions of WSH. The ability to give arguments a unique name has practical advantages for callers and scriptwriters. If you name every argument, callers will find a script easy to launch because they won't need to know or remember all the argument details. They only need to know about the arguments that pertain to them. And if you change the script, you don't need to train all the callers again, just those callers affected by the changes. Finally, because you have the flexibility to identify parameters by name and position, you can enhance existing scripts while minimizing the risk of breaking the code.