 Hating VBScript
started 10/27/2001; 12:32:11 PM - last post 10/29/2001; 7:00:18 PM
|
|
Ehud Lamm - Hating VBScript 
10/27/2001; 12:32:11 PM (reads: 2968, responses: 7)
|
|
|
|
Andreas Fuchs - Re: Hating VBScript
10/27/2001; 4:10:20 PM (reads: 2503, responses: 0)
|
|
|
Note that it does not even touch on my favorite pet VBScript (as of <= 5.x, I don't know about the most recent version, but all earlier versions had it) peeve: Stupid and/or execution.
In any serious language, the statements:
(define (foo)
(display "foo")
(newline)
#t)
(define (bar)
(display "bar")
(newline)
#f)
(and (bar) (foo))
will result in only "bar" being printed (and #f being returned), and
(or (foo) (bar))
will result in only "foo" being printed, as the boolean false that bar returns makes further execution useless (as does the boolean true that foo returns for the or statement).
Not so in VBScript.
in a series of statements in the form
s1 and s2 and s3
or
s1 or s2 or s3
VBscript evaluates all of these statemens, and then decides whether they are true or false. How very efficient (not to mention functions with side effects, as I have used in the examples above)!
|
|
Adam Vandenberg - Re: Hating VBScript
10/27/2001; 9:38:52 PM (reads: 2499, responses: 0)
|
|
|
I like short-circuit evaluation, but I'm not a big fan of logic clauses with side effects.
BUT the logic clause doesn't even have to have (much of) a side effect for VBScript to get annoying.
You can't do this in VBScript because both sides are evaluated:
if (not cint(x)) or (cint(x) = 0) then
Some default case where we treat x as 0
else
X is a number, do something
end if
You can rewrite the code in any number of ways, but that sort of thing still gets me because I'm more used to C programming.
|
|
Dan Shappir - Re: Hating VBScript
10/28/2001; 8:43:34 AM (reads: 2477, responses: 0)
|
|
|
This is a VB issue, not just a VBScript issue. MS tried to change this behavior in VB.NET only to get a huge pushback from developers. Apparently this change was going to break way to much code. MS rolled back this change and introduced two new operators: AndAlso and OrElse. These operators do perform short-circuit evaluation.
BTW being a co-author of Beyond JS, I really would like you guys to check it out. Sjoerd and I have been working hard in our spare time to create a library that merges both OO and Functional programming. At the very least, you should find interesting ideas and cool JavaScript code. Any feedback would be most welcome.
|
|
Ehud Lamm - Re: Hating VBScript
10/29/2001; 12:52:57 PM (reads: 2428, responses: 0)
|
|
|
Notice that many language desginers put forward good reasons for leaving the order of evaluation of function arguments unspecified.
If the logical operators are handled as regular functions (overloading), this means you can not ensure short circut evaluation.
I prefer the approach of having special operators for short circut evaluation. BTW, Ada has them to: "and them" / "or else". Now you should use these when you depend on short circut semantics, or else..
|
|
Adam Vandenberg - Re: Hating VBScript
10/29/2001; 1:10:15 PM (reads: 2444, responses: 0)
|
|
|
In college I managed to test out of the first year of computer courses.
I was talking with some friends of mine in the C++ course (which I skipped) and they were doing a section on operator overloading for classes.
The assignment was to make a Boolean class and overload the appropriate operators so that it behaved as you would expect.
Ugh! When you overload the logic operators in C++ it turns off short-circuit.
|
|
Ehud Lamm - Re: Hating VBScript
10/29/2001; 1:18:14 PM (reads: 2427, responses: 0)
|
|
Beautiful 
|
|
Chris Rathman - Re: Hating VBScript
10/29/2001; 7:00:18 PM (reads: 2429, responses: 0)
|
|
|
The author misses the biggest hole in the VBScript class construct - class inheritance is no where to be found. At least they didn't propogate the silly interface mechanism that was given in VB5, where there's no inheritance and we're tortured by the name mangling between the names given in the interface and the name given in the implementation.
|
|
|
|