I am looking to put a proposal to VB to get some pattern support that fits within the guidelines of what enhancements VB language can get. The first is the declaration pattern. To address the patterns below
Select Case x Case TypeOf x is Something Dim y as Something = x Case TypeOf x is SomethingElse Dim z as SomethingElse = x End Select If TypeOf x is Something then Dim y as Something = x End if
What I need to complete it is a VB like syntax that works for both and is extensible. If should be clear for any programmer that can read VB what is happening.
Awaitgot implemented as both an operator and a statement. On a technicality, your example begins with
oErrors...- i.e. the letter "o" and not "(". In that example,
Awaitis an operator, forming an expression which then returns an object that (presumably) has a member named
Errors, which in turn gets invoked and returns something that becomes the parameter to the
oErrors. While the distinctions between "statement" and "expression" tend to get fuzzy in real programming languages (e.g. https://therenegadecoder.com/code/the-difference-between-statements-and-expressions/), in at least the academic sense the differences are meaningful, and some languages enforce this dichotomy more sharply. E.g., C/C++ are super fuzzy, yet Java (although leveraging C/C++ idioms) is decidedly restrictive (and C# follows these Java restrictions).
Newexpression to be a statement, and I guess nobody saw a compelling reason to then allow it in the VB.NET design. I do not understand why anything like
new some_type().someMethod();is a good coding pattern, but I guess the C++ folks have liked it well enough (for whatever reasons of their own) that the Java designers allowed it.
new some_type().someMethod();in VB.NET to be anything terrible or atrocious or particularly wasteful.
Namespacecome to mind). The Java docs say (simply), FWIW: "Statements are roughly equivalent to sentences in natural languages. A statement forms a complete unit of execution."
@VBAndCs I believe the reason why it works with CALL is that you are essentially passing an expression result (hidden variable) to a function (CALL) - without the CALL keyword, the code appears invalid syntax. Some of this harkens back to the original days of BASIC where each instruction (line) consists of "instruction number, an operation, and an operand." (Quoted from the original BASIC manual circa 1964.) Obviously we eventually moved away from including the instruction number... but the operation and operand pattern actually makes perfect sense. The confusion regarding this very valid pattern came into play when personal computers (due to lack of memory) added the ability to drop the LET keyword - however, it can be argued that it is simply inferred. Anyway the general concept for BASIC is each statement starts with a keyword (except, of course, for variable assignment - one reason why I'd like to see LET return, at least as an option for teaching beginners) - and although New is a keyword... it's really about creating a new variable... thus not a keyword in the sense of the accepted pattern (IMO). I would add that in the specific example, you could also do the following:
If (New PayCheckWnd).ShowDialog = OK Then
But again... I'm basically creating a throw-away variable as part of an expression... not a direct non-keyword command.