VBScript Quiz Answers, Part Eight

VBScript Quiz Answers, Part Eight

  • Comments 7

8) Which of these programs is syntactically legal?

(a)
Class Bar
  Function Foo
  End Function
  Function Foo
  End Function
End Class

(b)
Class Bar
  If Blah Then
    Function Foo
    End Function
  Else
    Function Foo
    End Function
  End If
End Class

(c)
If Blah Then
  Function Foo
  End Function
Else
  Function Foo
  End Function
End If

(d)
Select Case Blah
  Function Foo
  End Function
Case True
  Function Foo
  End Function
End Select

Only (c) is legal, the rest are illegal. None are legal in VB6.

(a) is illegal because it is illegal to define the same procedure twice inside a class. (b) is illegal because only procedure and variable declarations are legal inside a class.  (d) is illegal because you cannot put a function between the Select and Case statements.

There are three interesting facts about (d).

First, it is legal to redefine a procedure at the global level. Silly, but legal.

Second, the syntax error raised by the parser is on the Case statement, bizarrely enough.

Third, bizarrely enough it is legal to declare a procedure inside a Case, just not between a Select and a Case.

(c) is legal. Due to a mistake in the VBScript 1.0 parser, we didn't check to see if functions were inside global-code If or Case statements, and we didn't check to see if they were redefined. This is totally an oversight -- it was not intentional. They're treated by the code generator as though the last one wins, and as though they were declared at global scope. There is no way to do "conditional compilation" here -- the last one wins no matter which branch of the conditional is executed.

I wanted to fix this in VBScript 2.0, but we couldn't because we discovered that many ASP page authors accidentally put function declarations inside If blocks, and we didn't want to break them all. (We'll run into this problem again in #10.)

When I implemented classes in VBScript v5.0 of course there was no previous version of classes to be compatible with, so I tightened it down; a class may not redefine functions. And since a class scope does not allow conditional statements, the problem with functions inside conditionals goes away inside classes.

Many of these quiz corner cases illustrate an important point: get the language design and implementation right the first time, because you're stuck with it forever!

 

  • "Many of these quiz corner cases illustrate an important point: get the language design and implementation right the first time, because you're stuck with it forever!"

    Forever? How about if you append ".NET" to to the name? Then you can make any changes you want without regard for compatibility. On the upside, it does give you an opportunity to clean up some messes, and I can't argue with the work opportunities it generates.
  • I reject the premise of your argument. As Paul notes on his blog (www.panopticoncentral.net), we _agonized_ over every backwards-compatibility breaking change going from VB6 to VB.NET.

    And as I have noted many times in this blog, we agonized over every compat-breaking change when implementing JScript.NET.

    And I'm sure that Stan Lippman agonized over every change to managed C++ as well.

    Ultimately you have to realize that VB.NET is not VB7. Think of it as an entirely new language that was designed to be easy for VB6 programmers to learn.

    When you think about it like that then VB.NET no more breaks backwards compatibility with VB6 than, say, Java breaks backwards compatibility with C++. They're different tools. And sometimes you really have to make that revolutionary leap and break with the past in order to advance.

    That Microsoft has collectively done a poor job of messaging this is regrettable, to be sure. But one thing comes through loud and clear: the future of wide-scale application development on Windows lies in managed code. Unmanaged languages like VBScript, JScript, VB6, C, etc, will continue to be important, of course. Work will continue to be done in them, and their runtime libraries will continue to exist and be shipped with Windows. But the kinds of massive developer productivity improvements I personally want to see in this industry will be enabled by the managed framework.
  • > Think of it as an entirely new language that was designed to be easy for VB6 programmers to learn.

    Eric evades the question by creating a new language. While you guys were in there breaking crap, it would have been very helpful to have an "Option Really Strict" that enables short-circuiting booleans without the absurdity of "OrElse", arrays that are base 0, and other things VB developers beyond the Mort level are perfectly comfortable giving up.

    However, you bring up a good point. This is what's so great about using IL as the base "language"-- you can constantly define new, potentially *radically* different and/or improved languages that leverage the same runtime. For example, Python.NET. It's genius!

    In Java, on the other hand, you can use any language you want, as long as it's Java. That's not exactly a recipe for radical innovation.
  • Why is "OrElse"/"Or" any more absurd than || vs | ? I would say that the former makes a whole lot more sense than the latter. The former clearly calls out the short-circuit nature, whereas the latter is just a typo waiting to happen.

    And indeed, the .NET strategy was from day one a fundamentally multi-language strategy. The .NET strategy is "use any language you want, we want to make our platform attractive to all developers".

    As Joel once pointed out, the Java strategy is "use any Java runtime implementation you want, we want to make a platform that makes hardware choice irrelevant". Since Sun is a hardware company, their strategy doesn't really work well with their business model.
  • "I reject the premise of your argument."

    Reading it again, "anything you want" is too strong though and sounds like Microsoft didn't carefully consider the impacts. I know you did. Sorry. Yet, had Microsoft created VB7, you would have to agree the "agonized but still changed" list would have been much shorter, and that was my point.

    "And indeed, the .NET strategy was from day one a fundamentally multi-language strategy."

    What disappoints me about .NET is that all the Microsoft languages are about equal in expressive power. So I agree with Jeff on that point. There is not much point in going to all the work of developing multiple language engines with different syntax but exactly the same features.

    All the languages are also excessively and consistently verbose for the functionality they implement. The programmer is still left with too many bookkeeping chores (IDispose) for things they need to do regularly. I would like to have seen some innovative language design thinking, like the regular expressions of Perl 6 or the XML handling of EcmaScript/E4X.
  • > What disappoints me about .NET is that all the Microsoft languages are about equal in expressive power.

    I agree. Though of course I cannot talk about hypothetical future features of language products, I will say that the VB team has received PLENTY of feedback saying that VB.NET can be more than C# without braces. There are LOTS of innovative ideas at Microsoft for what to do in the language space. Like Scott Wiltamuth once said, we've barely scratched the surface here.

    Generics, anonymous functions, and the yield statement make construction of abstract data types, delegates and enumerators much less verbose, and they're coming up in Whidbey. There is still PLENTY left to do in the XML, data management, etc, spaces. I think you'll be pleasantly surprised by future innovations.

  • PingBack from http://websitescripts.247blogging.info/fabulous-adventures-in-coding-vbscript-quiz-answers-part-eight/

Page 1 of 1 (7 items)