optional param in Method

[Rick]

VS2005 Pro

I have confusing results from an optional parameter in a method.
Public Shared Function Parameter(ByVal parameterName As String, ByVal
parameterValue As Object, Optional ByVal db_Type As FbDbType = Nothing) As
FbParameter

FbDbType is an enumeration with 0 = "Array", 1 = "BigInt" etc.

When I call this method and omit the db_Type value like this:

myParam = Parameter("param1", 1234)

the value of db_Type is "Array" rather than "nothing" like I expect. I
suspect this has something to do with the fact that the db_Type is really an
Integer type and cannot be initialized to "Nothing". I need to test if
db_Type has been initialized in my method and assign it to a var in the
method.

Is my suspicion correct and is there some other way to do this?



Regards,

Rick

 

[Armin Zingler]

VS2005 Pro

I have confusing results from an optional parameter in a method.
Public Shared Function Parameter(ByVal parameterName As String,
ByVal parameterValue As Object, Optional ByVal db_Type As FbDbType =
Nothing) As FbParameter

FbDbType is an enumeration with 0 = "Array", 1 = "BigInt" etc.

When I call this method and omit the db_Type value like this:

myParam = Parameter("param1", 1234)

the value of db_Type is "Array" rather than "nothing" like I expect.
I suspect this has something to do with the fact that the db_Type is
really an Integer type and cannot be initialized to "Nothing". I
need to test if db_Type has been initialized in my method and assign
it to a var in the method.

Is my suspicion correct and is there some other way to do this?

Do not use the keyword Nothing with value types. It is allowed but it
should not be. An Enum is a value type. Assigning Nothing to a value
typed variable means assigning the "default value". An enum is stored as
an Integer value. An Integer's default value is 0 (zero). So, the
signature is identical to:

.... Optional ByVal db_Type As FbDbType = 0....


Armin

 

[Bob Altman]

Do not use the keyword Nothing with value types. It is allowed but it should

not be.

FYI, the ability to assign Nothing to value types was added so that generic
methods can assign Nothing to a variable even if the variable is a value type.
One use of this is to allow a caller to pass a value of Nothing to a generic
argument. Of course, the generic routine needs to add some code to determine
whether the generic argument is a value type or a reference type before trying
to make sense of the Nothing that may have been supplied as an argument.

Bob

 

[Steve Gerrard]

trying to make sense of the
Nothing that may have been supplied as an argument

There is something very Zen about that; plus, it also applies to lots of
discussions at the water cooler, or in this newsgroup for that matter.

 

[Rick]

Thanks for the input everyone.

I have modified my procedure to:
Public Shared Function Parameter(ByVal parameterName As String, ByVal
parameterValue As Object, Optional ByVal db_Type As FbDbType =
FbDbType.VarChar) As FbParameter

FbDbType.VarChar is the default for an FbParamter.FbDbType, so now in the
procedure I just check:

if not db_Type <> FbDbType.VarChar... and reset if not

Rick

 

[Chris Dunaway]

Thanks for the input everyone.

I have modified my procedure to:
Public Shared Function Parameter(ByVal parameterName As String, ByVal
parameterValue As Object, Optional ByVal db_Type As FbDbType =
FbDbType.VarChar) As FbParameter

FbDbType.VarChar is the default for an FbParamter.FbDbType, so now in the
procedure I just check:

if not db_Type <> FbDbType.VarChar... and reset if not

Rick

Why not just add an item to your enumeration called NotSet with a
value of -1 or something like that. It seems that would make the code
more clear.

Chris

 

[rowe_newsgroups]

if not db_Type <> FbDbType.VarChar...

Wouldn't If db_Type = FbDbType.VarChar be easier? The "if not ... does
not equal" is a bit confusing

Also, you could declare the optional parameter as a Nullable(Of
FbDbType) and then you would have the ability to properly set it to
'Nothing', though you would have to modify how you inspect / use the
variable a bit.

I also would recommend overloading your methods instead of using
optional parameters. It might just be personal preference, but I
rarely see any good come out of optional parameters.

Thanks,

Seth Rowe [MVP]

 

[Bob Altman]

I also would recommend overloading your methods instead of using

optional parameters. It might just be personal preference, but I
rarely see any good come out of optional parameters.

Optional parameters are phenomenally useful for routines authored in and
consumed by VB. But neither C++ or C# are happy with them, so you should
think twice before you use optional arguments on public methods of a public
class if there is any chance that someone will come along in one of those
languages and try to use your libraries. As I recall, C# is reasonably
benign -- it just treats your optional arguments as required arguments. C++
issues compiler warnings for any optional arguments it encounters. I have
no idea what happens if you actually try to call a from C++ that has
optional arguments (I've never tried that).

Bob

 

[rowe_newsgroups]

Optional parameters are phenomenally useful for routines authored in and
consumed by VB. But neither C++ or C# are happy with them, so you should
think twice before you use optional arguments on public methods of a public
class if there is any chance that someone will come along in one of those
languages and try to use your libraries. As I recall, C# is reasonably
benign -- it just treats your optional arguments as required arguments. C++
issues compiler warnings for any optional arguments it encounters. I have
no idea what happens if you actually try to call a from C++ that has
optional arguments (I've never tried that).

Bob

Though I'll tend to disagree about there usefulness in VB (I would
rather see overloading), your post definitely elaborates on why I
always try to leave out the optional params. Outside of upgrading
legacy applications without doing to much rewriting, they really
should be ripped out and replaced with overloaded methods (imo).

Thanks,

Seth Rowe [MVP]

 

[Michael D. Ober]

Though I'll tend to disagree about there usefulness in VB (I would
rather see overloading), your post definitely elaborates on why I
always try to leave out the optional params. Outside of upgrading
legacy applications without doing to much rewriting, they really
should be ripped out and replaced with overloaded methods (imo).

Thanks,

Seth Rowe [MVP]

In addition, methods with optional params are not CLR compliant. No other
dotNet language can see them. That said, if you are working primarily in VB
and have internal interfaces that only VB will call, they are extremely
useful.

Mike.

 

[Tom Shelton]

In addition, methods with optional params are not CLR compliant. No other
dotNet language can see them.

You can see and call them from C# - it's just really ugly.

That said, if you are working primarily in VB
and have internal interfaces that only VB will call, they are extremely
useful.

Other then maybe reducing typing, they are no more useful then
overloading.