Why we need Option Strict Off
Comments(8) I was reading Bill Ryan’s blog rant about Option Strict Off, and although I whole heartedly agree with him when it comes to writing .NET code, (that is turn Option Strict On and leave it On !!), I think some folk have missed the point as to why VB.NET has Option Strict Off.
Now if you had said it was because of VB6 code, well you would be partially correct. The real answer is to make it possible to work with COM as we know it, and most importantly to make it simple and elegant to work with COM objects. Like it or not, history has bequeathed us with a plethora of IUnknown, of COM interfaces that by definition are late bound. Even in Visual Studio .NET, the macro recorder relies on this very thing to bridge the world of COM to the world of .NET. (hint, record a heap of macros then turn Option Strict On and see what happens )
That’s not to say that you can’t work with the COM objects without Option Strict Off — In fact you can, BUT it requires more code. And I must admit I think I have just about always ended up turning Option Strict On, even in my VS.NET macros…. but sometimes I think that’s just the pedantic in me
The real problems lay not in the ability to use Option Strict Off/On, but in its lack of visibility (sometimes) and it’s lack of granularity.
To address the visibility, make the declaration explicit in each and every one of your code files. Oh and send emails to the VB team asking them to make it visible if set at project level either in a toolbar button or even status bar etc.
To address the granularity, well at present try to factor your code out to a separate code file that has Option Strict Off in it. Usually though it’s not worth the pain. IN VB.NET 2005 you can get a similar effect a bit nicer by using partial classes, thus splitting your class file into separate code files, hence allowing you to compile some of the class’s code with Option Strict On, and some with it Off.
Oh, and long term, well keep sending the VB team those emails. I would suggest making suggestions such as :
#Begin Option Strict Off
#End Option Strict Off
Or some block construct like that so as we can use Option Strict Off like it was intended to be used without forcing a whole heap of our code to also be Option Strict Off.
Totally agree with you. THere are times when it’s necessary – so be it – I have no issue whatsoever there. It’s just that people that leave it off because "it helps me code faster" or ______(fill in lame excuse) that’s when it’s an issue. I think the ability to turn it off is a positive – I just think it should be on by default.
Hi Bill,
Yep, definetly On by default. But to change that now, they need to address the visibility thing, which of course would have lots of other positives. nad if they make it more granular, I think folks will tend to use it more wisely
Agree. But just a nitpick by way of correction, IUnknown doesn’t cause late binding, IDispatch does that.
I think that would be a good suggestion with the essentially block-level setting of option strict on/off.
I like the idea of regions. I’m just not a fan of the actual text you chose. I’d prefer something that makes it very clear that you are relaxing the type checking. You shouldn’t have a keyword to enforce it for a section.
So, I’d propose something like:
#Relax Option Strict
‘Code with relaxed type checking
#End Relax
This would enforce the fact that you are doing something potentially unsafe. And, it would also force you delineate the code that allows this (instead of the other way).
Hi Bill,
Couldn’t agree more. I mentioned to Bill that the irony is that people see having it off as a newbie thing. Having Option Strict off should be considered an advanced technique! I like the idea of having regions for it but if we’re going to pick a name, I like Martin’s suggestion.
Regards,
Greg
Hi Scott,
IDispatch is the mechanism by which we do late binding, but IUnkown defintions is the cause of API that have parameters/return types "As Object"
Hi Greg & Martin,
Maybe we should bat this around a bit more … I think the # is good, as that is in keeping with compiler directives (not regions)
But I don’t like the Relaxing as such, because then we would need another for Tighteneing. And now in 2005, we have more granular control of compiler switches, albeit only at project settings level, but ideally we should be able to apply any of the switches On/Off at a block scope. so concepts of Tightening/Relaxing would probably just complicate things…
How about:
#Compiler Option Strict Off
#End Compiler Option
or just :
#Option Strict Off
#End Option
Bill,
touche!
Happy new year man!