VB 10 thoughts (part 2)

Continuing thoughts on the language from yesterday :

  1. Multiple assignment
    Todd suggested this yesterday in reply to my post.  I don’t like the use of the := syntax, rather I’d like to see a grouping used, such as :
    (x, y) = 5
    That would be the equivalent of x = 5 : y = 5
  2. Differentiate between equality and assignment operators
    In C style languages equality operator is == and assignment is =.  In VB, both equality and assignment are =. VB also uses := for assignment to named parameters.  Despite all my years of VB, I still find this hard to read at times.  To determine what = means you have to look at not just the operands but the context of the entire statement. When you add lambda functions to the mix, especially multiple statement ones, then the code is not always clear as to what it is doing, instead you have to decipher it by looking for clues in the context around the statement.
    My first thought was to have a == similar to C style languages, but that would only work if it was enforced through out, meaning you could not use = for equality testing. This would require the IDE to update all existing source code and as such would be a maintenance nightmare for a lot of folks.  The outcome would be good, but the road to getting there would be painful.
    If instead we ensure that code as it stands today continues to work the same without being updated, then it really limits us to changing the assignment operator, not the equality one. For example, you might be able to use := for assignment where the context is unclear (I’m thinking lambdas here mainly), but you could still use = for assignment in other places.  Although this solves the functional issues we might see around multi statement lambdas it doesn’t solve the readability issue I still struggle with 😉
    Perhaps the solution to this is a combination of factors. Go for the no break fix by using := where needed, and also have the IDE change the visual appearance of = as assignment compared to equality, e.g. paint one red and the other blue, or even have an option of a glyph that gets rendered there.


  3. Stop having multiple meanings for keywords and symbols
    VB isn’t too bad in this respect compared to some other languages.  Typically VB is verbose in saying exactly what code declarations are by having many keywords rather than multiple meanings to the same keywords.  One obvious exception is arrays (indexers) versus method calls. I think I’d like to see []’s used here or a visual differentiation in the IDE. Going forward, sometimes it makes sense to give a new meaning to keywords that is in keeping with their original meaning.   I’d call this expanding the usage, not giving it an alternative meaning. A good example is the expansion of With to it’s usage in object initializers. Another good example is the expansion of Where from a filtering clause on Catch blocks to a general clause in LINQ queries.  An example of bad double meaning is the using statement in C#, where it is used for both a namespace imports and a IDisposable block of code


  4. Implicit interface syntax.
    I love VB’s explicit interface mapping. Not only is it incredibly powerful, empowering the true mapping that can be done at IL level, it also makes code very clear as to what methods are for which interfaces.  But at times, especially when the code is generated for you elsewhere, it would be nice to have an implied interface syntax that doesn’t require modifying the code for the methods, e.g.:
    Public Class Foo
         Inherits somebaseclass
         Implements IThingy ‘ explicit implementation needed
         Implies ISprocket ‘ implied interface matched by name and signatures.


2 Comments so far

  1.   Bob Bingham on October 8th, 2007          

    I think I would pull for an IDE change on 9 and 10. Colors or shading should work fine, I would think.

    Another thing the IDE might indicate is reference vs value types. It’s easy for new and even experienced VB programmers to get confused on this. Maybe have slightly different shades for the variables. Also add a help bubble to “byval” and “byref” in sub/function definitions that’s sensitive to the variable type and could spell out exactly what will happen. Those changes would help out in learning, IMHO.

  2.   bill on October 8th, 2007          

    yep ! I plan to write about some visual concpets a bit further down the track. It takes a bit longer as I need to actually do some screen shots so as peopel can grasp what I mean.