To view parent comment, click here.
To read all comments associated with this story, please click here.
With regards to "WithEvents" - yes probably. But that's not what the MSDN says. As far as I can see, it's required when the "handles" clause is being used. That's not really legacy then.
No it's not... not in the "you can't use the wrong type because it won't compile" sense of the notion. VB will happily munge and cast between integral types and Decimal/Double. VB will silently cast a Boolean to an integer. This should not compile, but it does:
Dim X as Boolean
Function WFT as Boolean
Return X
End Function
....
Switch Case Y
Case WTF ''This could be anything
....
Yeah, probably. But when you have to run code to verify that fact, it's screaming "walk away" to me.
And the compiler silently casts the Bool to an Integer. That might be how VB6 worked, but VB.Net uses the CLR and so an explicit cast is required. How helpful VB.
Oh, and rewinding to "type safe".. try turning off Option Strict and Option Explicit and see how much worse you can make stuff... you don't even need to declare the return types of Functions... VB just guesses for you and silently casts the result to the type you assign the result to. Even with it on, you can still do everything else I mention. The first thing I do with VB code these days is look at the project properties and if it isn't already set, build it with Option Explicit and Option Strict turned on and fix all the errors. It is far, far too common to still find shops using VB.Net as if it was VB6.
I agree with you that VB is terrible, but it doesn't make it type-unsafe because of it.
I think casting is more of a gray area and VB.NET definitely has more ambiguity. Its harder to know at a glance if something is correct.
C# does some implicit casting too, if you define an implicit operator overload. I'm sure VB.NET does something similar to manage to stay within the CLR sandbox.
What VB.NET does imho, is wrap bad ideas around syntax. Examples being like you said implicit conversions (which imo have always been a bad idea no matter the language) and implicit late binding.
VB.NET takes late binding, implicit typing, and implicit casts and muddies the waters into this incomprehensible soup of syntax.
However, it is still easy for VB developers to pick up VB.NET . That's always been the reason imo for VB.NET's existence. I'd never write any meaningful amount of code using it.
I think any time someone uses dynamic in C#, late binding in VB.NET or find yourself using some of these more weird features, they need to step back and think about what the hell they're doing.





Member since:
2005-11-29
Oh jesus.. no it's not! Here is an example:
Define a class and on that class create a public event
I don't think what he said is untrue, just less true for some than others. People with a strong VB background have picked up VB.NET rather quickly (to my dismay, Id rather see it die a cold death, but ah well)
I think your counter-point underlines his point quite well though, in that WithEvents is a construct included in VB.NET for pure legacy reasons.
C# has the advantage of being able to learn from the mistakes of other languages, whereas when VB.NET was being developed, they likely valued VB familiarity over purity.
That's why you can do stupid things in VB.NET, but you can also do stupid things in C++, in Java, and in C# (Look at boxing before Generics for example).
C# not having as many ways to shoot your foot off is a testament to C# as a language, sure.
VB is dangerous, plain and simple and there's nothing you can do in VB that can't be done in a safer .Net language at a similar speed.
VB.NET is completely type safe.
Also, the switch statement with a boolean is probably going to evaluate to zero, because that's what a bool of false (default value for the bool value type) evaluates to when converted to an int.