optional param in Method

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
Fri Mar 14 16:58:38 CDT 2008

"Rick" <RickREMOVETHIS@LakeValleySeed.com> schrieb
> 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
Fri Mar 14 19:09:11 CDT 2008

> 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
Fri Mar 14 19:58:51 CDT 2008

Bob Altman wrote:
>
> 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
Sat Mar 15 09:17:55 CDT 2008

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

"Rick" <RickREMOVETHIS@LakeValleySeed.com> wrote in message
news:%23%23VLAvhhIHA.1408@TK2MSFTNGP03.phx.gbl...
> 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
>
>

Chris
Mon Mar 17 09:52:38 CDT 2008

On Mar 15, 9:17 am, "Rick" <RickREMOVET...@LakeValleySeed.com> wrote:
> 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
>
> "Rick" <RickREMOVET...@LakeValleySeed.com> wrote in message
>
> news:%23%23VLAvhhIHA.1408@TK2MSFTNGP03.phx.gbl...
>
> > 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

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
Mon Mar 17 10:23:18 CDT 2008

> 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
Mon Mar 17 19:30:36 CDT 2008

> 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
Tue Mar 18 06:24:28 CDT 2008

On Mar 17, 8:30 pm, "Bob Altman" <r...@nospam.nospam> wrote:
> > 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

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
Tue Mar 18 07:07:03 CDT 2008

"rowe_newsgroups" <rowe_email@yahoo.com> wrote in message
news:4f16d1b6-dd78-4127-9083-13ba11263355@q78g2000hsh.googlegroups.com...
> On Mar 17, 8:30 pm, "Bob Altman" <r...@nospam.nospam> wrote:
>> > 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
>
> 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
Tue Mar 18 11:23:24 CDT 2008

On 2008-03-18, Michael D. Ober <obermd> wrote:
> "rowe_newsgroups" <rowe_email@yahoo.com> wrote in message
> news:4f16d1b6-dd78-4127-9083-13ba11263355@q78g2000hsh.googlegroups.com...
>> On Mar 17, 8:30 pm, "Bob Altman" <r...@nospam.nospam> wrote:
>>> > 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
>>
>> 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.

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.

--
Tom Shelton