Optional Parameters

[Joe Cool]

I take it Optional Parameters for functions are not supported in
C#.NET. Is there a workaround of some type?

[Michael Weber]

"Joe Cool" <jo*****@home.netskrev i en meddelelse
news:3u********************************@4ax.com...

I take it Optional Parameters for functions are not supported in
C#.NET. Is there a workaround of some type?

[Michael Weber]

"Joe Cool" <jo*****@home.netskrev i en meddelelse
news:3u********************************@4ax.com...

I take it Optional Parameters for functions are not supported in
C#.NET. Is there a workaround of some type?

Keyword "params".

.....Method( params object[] list ){
....}
Method( "hola",1,new object());
Best regards,
Michael Weber

[Mr. Arnold]

"Joe Cool" <jo*****@home.netwrote in message
news:3u********************************@4ax.com...

>I take it Optional Parameters for functions are not supported in
C#.NET. Is there a workaround of some type?

It's called Method Overloading.

http://www.codersource.net/csharp_me...roperties.html

You have Method Overloading in VB.Net as well.

[Bob Grommes]

Optional parameters are not quite the same as either params[] or
overloading, but overloading usually serves fine.

Where VB's optional parameters come in handy, really, is when you call
into those obscene automation APIs in Office and elsewhere ... you know,
the ones where you have twenty-five parameters and you only need to use
the first two, and furthermore, you likely will never use the other
twenty-three. You can make the same call in C#, but it requires more
effort.

This little convenience is why VB is preferred by some for automation
work, although I suspect it either increases call overhead or involves
late binding under the hood. But it's an edge case. For everyday work,
overloading does the job and arguably does it better.

--Bob

Joe Cool wrote:

I take it Optional Parameters for functions are not supported in
C#.NET. Is there a workaround of some type?

[Alun Harford]

Bob Grommes wrote:

Optional parameters are not quite the same as either params[] or
overloading, but overloading usually serves fine.

Where VB's optional parameters come in handy, really, is when you call
into those obscene automation APIs in Office and elsewhere ... you know,
the ones where you have twenty-five parameters and you only need to use
the first two, and furthermore, you likely will never use the other
twenty-three. You can make the same call in C#, but it requires more
effort.

This little convenience is why VB is preferred by some for automation
work, although I suspect it either increases call overhead or involves
late binding under the hood. But it's an edge case. For everyday work,
overloading does the job and arguably does it better.

Good advice.

Another option is to go the OO way, and create an object to encapsulate
the arguments for your method.

Alun Harford

[Bob Grommes]

In the specific case of an existing API like the one I described, that's
poorly designed in the first place ... no joy. But yes, any time you
have that much info to pass in, it's screaming for a class wrapper.

--Bob

Alun Harford wrote:

Bob Grommes wrote:

>Optional parameters are not quite the same as either params[] or
overloading, but overloading usually serves fine.

Where VB's optional parameters come in handy, really, is when you call
into those obscene automation APIs in Office and elsewhere ... you
know, the ones where you have twenty-five parameters and you only need
to use the first two, and furthermore, you likely will never use the
other twenty-three. You can make the same call in C#, but it requires
more effort.

This little convenience is why VB is preferred by some for automation
work, although I suspect it either increases call overhead or involves
late binding under the hood. But it's an edge case. For everyday
work, overloading does the job and arguably does it better.

Good advice.

Another option is to go the OO way, and create an object to encapsulate
the arguments for your method.

Alun Harford