Support strong-typed nullable data types.
In VBA, we can only store nulls in a Variant data type. But I hate this because this lacks information whether this is a string, a number or date. In SQL, those data types are all nullable but we have to constantly do Nz(), IsNull(), to avoid the nefarious error "Invalid use of Null".
Please make it possible for us to specify a nullable data type so that we also know this can be only either a null or a number (and thus prevent invalid entries of string in addition to writing self-documenting code).
B. Clothier
shared this idea
4 comments
-
Mark Burns
commented
@Ben,
How could they modify the VBA environment to accept the new (built-in?) class types as variables usable in calculations and normal arithmetic expressions without modifying the underlying implementation code to accept the new classes? Also, the rules of operation for expression evaluation would have to be modified (or at least reconsidered) to allow for the proper handling of the nullable concrete variable class types. So, I can't see them doing that as those changes would necessarily affect ALL VBA implementations across not only Access and Office, but all other VBA consuming applications (i.e. AutoCAD) out there.
Now, understand that I'd still be all for that, of course, but it seems to me to fly too much against MS' previously stated position on NOT making any significant VBA changes/improvements going forward.
-
Adrian Bell (MVP)
commented
When I first read this I assumed it was requesting a change to the existing set of variable types. I am strongly opposed to that.
Now that I understand it's not such a limited, and limiting, proposal I can support it (when some votes get freed up :-( ).
-
B. Clothier
commented
@Mark, that's true but there's also the possibility that they can just box it as custom classes for use within Access object library or similar avenues. That wouldn't require modifying the VBA and still achieve the goal of making it easier to work with nullable data types in code.
-
Mark Burns
commented
I would SO vote for this idea, but it flies in the face of MS' previous declarations that they WILL NOT be seeking to seriously revamp or otherwise improve the VBA development environment, and in order for this idea to take root, new VBA Data types would need to be brought into existence, and it seems that they are not willing to think along those lines, unfortunately.