From: rconn
| Quote:
|| This is not documented except under What's New,
|
| It's mentioned briefly in SWITCH.
I presume that it must be possible to evaluate the expressions used as values in CASE statements independently of the expression in the SWITCH statement.
| Quote:
|| and does not specify whether or not the functions can depend on the
|| control expression of the SWITCH statement, and if so, how one
|| specifies that relationship.
|
| I don't know what you're referring to. You want to duplicate the expression
| specified in the SWITCH statement in the CASE statement? Why not just
| repeat it? It's probably not going to have changed (except possibly in
| CASEALL), unless you're using an expression with side effects
| (usually a bad idea).
For example to use @WILD in a match, as you suggested, I would need something like this:
CASE @wild[*,[012]]
to designate the SWITCH expression in the manner functions in PDIR represent the current filespec, indicating that I want this case to be the one selected if the expression contains any of the digits 0, 1, or2. However, I don't think this is legitimate syntax nor that it has any variations. See my comment above - this @WILD is not deterministic...
| Quote:
|| how would I specify each of the CASE rules below (I use all of these
|| tests in a single batch file, albeit mostly using IFF/ELSEIFF):
||
|| - any of the digits 0, 1, or 2
|| wildcard: [012]
|| - any digit 1 through 9
|| wildcard: [1-9]
|| - any digit 2 through 9 or any letter
|| wildcard: [2-9A-Z]
|| - any digit or letter except F
|| wildcard:[0-9A-EG-Z]
|
| @WILD.
I don't think one could use @WILD in a CASE clause of a SWITCH statement (they'd be OK in conditional expressions of IF/IFF/ELSEIFF/@IF).
|
| IMHO your desired SWITCH block is going to be much clumsier & harder to
| decipher (and debug) than an IFF block. It will also be slower.
Here is an example of what I'd like to be able to do:
switch %@left[1,%1]
case F
:: first char is letter F
...
wildcase [0-9]
:: first char is a decimal digit
...
wildcase [A-Z]
:: first char is a letter, other than F (because F was already processed)
...
default
:: first char in neither decimal digit nor letter
...
endswitch
IMHO this design is clearer and easier to decipher for a person than doing it with IFF blocks. Consequently it would be easier to debug.
1/ IFF would require either repeated evaluation of the control expression, or the use of an auxiliary variable
2/ each test could be made using @WILD or @REGEX, but would still require much longer syntax:
iff %@regex[[0-9],%@left[1,%1]] EQ 1 then
...
| Your proposed change to the SWITCH syntax would either require breaking
| existing compatibility or creating a new command.
Yes, there is an incompatibility. New syntax is needed, but it can be simple - since each CASE statement is interpreted only when it is the next test, one at a time, alternate statements WILDCASE (or WCASE) could be used to indicate that values are to be interpreted using the file specification wild card syntax; and REGEXCASE (or RCASE) indicate regular expression syntax. This would preserve backward compatibility. It could also provide simple syntax for a different enhancement: case sensitive matching, by suffixing the "CASE" cluase with S, i.e., CASES, to indicate case sensitive matching. The same suffixing could be used for RCASE and WCASE: RCASES and WCASES would specify case sensitive regex and wildcard matching, resp.
Whether or not the new CASE statements would make SWITCH effectively a new command I cannot tell - that depends on the method used by the current implementation. Likewise, I cannot tell without strong familiarity with the internals of both SWITCH and IFF implementation whether or not the new CASE statements would result in slower or faster execution than repeated IFF @WILD[] or IFF @REGEX[] tests. However, it is my guess that SWITCH would not be significantly slower than IFF, nor would it require a completely new design. The design enhancement that went into permitting a non-constant value for the comparison would probably need only a little tricking up to internally invoke the code used by @WILD or @REGEX to make the decision.
--
Steve
