Hi Bob,
<snipped>
Post by Bob Barrows [MVP]http://blogs.msdn.com/ericlippert/archive/2003/09/15/52996.aspx
Bob Barrows
Thanks for the follow-up. On re-reading it, my explanation probably was a
*bit* obscure to a new scripter. :-) Actually, this is one of my pet
peaves, and since it's a slow day ...
There's a post by Eric Lippert in a 1999 thread between Gunter Born and him,
which is likely clearer for beginners and for the black-and-white listing of
possibilities than is his blog. (Alex used to keep this posted on his
website.) Here's the cut and paste that I keep --
---------------
Good point, I didn't cover what happens when you use the Call keyword -- OK,
let's sum up with a code sample:
-----
Sub Bar( x )
End Sub
Sub Baz( a, b )
End Sub
Function Foo( y )
End Function
z = 123
n = Foo(z) ' legal, passes z by reference
n = Foo((z)) ' legal, passes z by reference
'n = Foo z ' illegal, parens required
Foo z ' legal, passes z by reference
Foo(z) ' legal, passes z by value
'Call Foo z ' illegal, parens required
Call Foo(z) ' legal, passes z by reference
Call Foo((z)) ' legal, passes z by value
'n = Bar(z) ' illegal, bar is not a function
Bar z ' legal, passes z by reference
Bar(z) ' legal, passes z by value
Call Bar(z) ' legal, passes z by reference
Call Bar((z)) ' legal, passes z by value
Baz z, z ' legal, passes z by reference
Baz (z), (z) ' legal, passes z by reference
'Baz(z,z) ' illegal, can't use parens
Call Baz(z, z) ' legal, passes z by reference
Call Baz((z), (z)) ' legal, passes z by value
'Call Baz z, z ' illegal, parens required
-----
This is what we in the programming language business call "a big mess".
Unfortunately, we're stuck with it for backwards-compatibility reasons.
Eric
---------------
Thread at
http://groups-beta.google.com/group/microsoft.public.scripting.wsh/browse_thread/thread/54eea1469d8aa6d7/5b67151d04c5efc8?q=function+%22option+explicit%22+group:microsoft.public.scripting.*+author:lippert&rnum=2#5b67151d04c5efc8
I agree with Eric Lippert that maintaining the CALL keyword is a syntactical
nuisance, but otherwise I don't see the situation as "a big mess." The
problem is that neither most posts nor most scripting references (including
the MS WSH documentation) approach the situation at a comprehensible level.
Parentheses serve three purposes in VBS. Two of these are surrounding the
arguments of an array and a function called for a return. These two are
actually closely related, because of the way the code is parsed, but that's
another story.
The general use for parentheses, since the beginnings of BASIC, is as an
operator. Most books and the MS WSH documentation teach that parentheticals
"group operators and statements", but it helps, instead, to understand that
parentheticals are actually operators, themselves, which isolate statements
and ensure that they are resolved to transitory value assignments.
Parentheses are simply an operator that preserves the value instead of
changing it. For example, the statements
2=2
and
(2=2)
both create a transitory value assignment, just like a function, with a
resolved Boolean value of True (as can be tested with TYPENAME). The
difference with parenthetical operators is that they can resolve even a
single variable statement to a transitory value assignment, *wherever* they
are used in script.
(xMyBooleanVariable)
The use of parentheses to effect a ByVal-effect in a function call is no
different than parenthetical use elsewhere in script. Any function return
or operator produces a transitory variable assignment and isolates the
underlying variable from default ByRef alteration in the called function.
For example, the following two function calls both protect the underlying
variable settings, for exactly the same reasons -- all of argument
references create a transitory value assignment, which is what is altered in
a the ByRef function call, instead of allowing the the defined variable
value to be altered:
myFunction (nNumber), (sStr)
myFunction nNumber *1, cstr(sStr)
Parenthetical operators are simply more efficient than are numerical, string
or conversion operators or functions.
A number of scripting anomolies and misconceptions clear up, if one just
keeps in mind that everytime one uses operators (including parentheses) or
obtains a return from either an inherent function or a user-defined
function, one is handling a transitory value assignment -- in essence, a
transitory variable. But I rarely see anyone or any source pitch it this
way.
Hope you have a pleasant Easter weekend.
Regards,
Joe Earnest