optional param in Method

  • Thread starter Thread starter Rick
  • Start date Start date
R

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
 
Rick said:
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?
Click to expand...

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
 
Do not use the keyword Nothing with value types. It is allowed but it should
not be.
Click to expand...

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
 
Bob said:
trying to make sense of the
Nothing that may have been supplied as an argument
Click to expand...

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.
 
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
 
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
Click to expand...

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
 
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]
 
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.
Click to expand...


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
 
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
Click to expand...

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]
 
rowe_newsgroups said:
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]
Click to expand...


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.
 
In addition, methods with optional params are not CLR compliant. No other
dotNet language can see them.
Click to expand...

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.
Click to expand...

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