basic: Is it possible to define optional parameters in a method declaration? how?

[Juan]

Thanks,
Juan.

 

[Patrick Altman]

Yes. Just overload the method.

public class MyClass
{
public void MyMethod(int x, int y)
{
...
}

public void MyMethod(int x)
{
MyMethod(x, 0);
}
}

Now you have a class with a "single" method, with two "options" of how
to call it.

Hope that helps.

Patrick Altman
<><

 

[Chris Rolon]

No, C# does not give you the ability have optional parameters like in C++ or
VB. The best that you could do is function overloading, as Patrick pointed
out.

 

[Juan]

I see. Thanks a los, i will overload then.

No, C# does not give you the ability have optional parameters like in C++ or
VB. The best that you could do is function overloading, as Patrick pointed
out.

 

[benben]

I shall disagree with you. C# comes with even better support for variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

No, C# does not give you the ability have optional parameters like in C++ or
VB. The best that you could do is function overloading, as Patrick pointed
out.

 

[benben]

I shall disagree with you. C# comes with even better support for variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

No, C# does not give you the ability have optional parameters like in C++ or
VB. The best that you could do is function overloading, as Patrick pointed
out.

 

[RCS]

This the most inappropriate use of params I've seen. I assumed there were
people that did this sort of thing, but this is the first time I've seen.

This is *NOT* how you should use params. Can you? Yes. Should you? No.

In fact, if you are going to propose that, why not just have EVERY method be
defined like this:


int Match(params object[] theobjects)
{ }

int Average(params object[] theobjects)
{ }

int ListNames(params object[] theobjects)
{ }

Why even bother defining specific parameters? I'll tell you why - because it
gives the developer a firm/known interface to write to and gaurantees the
expected data types and number of parameters.

The point is, making a loosely-coupled interface like this is really, really
asking for trouble - from the fact that it's not self-documenting, which
leads to developer confusion and assumptions (which lead to bugs), to an
inherent bug of what if you change the underlying behaviour - but don't need
to change the interface? That can and will likely lead to bugs with
applications that consume this object.

In other words, if I give you an object I made it has:

string CalculateItems(params object[] theobjects)

You immediately need more information: "What do I pass in there? Does the
order matter? What kind of data types?". Versus if I gave you:

string CalculateItems (int[] ProductIDs)

Then it's very clear (read: "self-documenting") - that this takes an array
of ProductIDs.. You see?


This is just bad, bad form, please don't encourage people to do this!! If
you want loosely coupled, go write in VB6 and make everything a variant!!

I shall disagree with you. C# comes with even better support for variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

 

[Chris Rolon]

As has been pointed out, your use of params is inappropriate. C# does not
support default arguments, ala C++, which I believe is what Juan was asking.

--

Chris Rolon

This the most inappropriate use of params I've seen. I assumed there were
people that did this sort of thing, but this is the first time I've seen.

This is *NOT* how you should use params. Can you? Yes. Should you? No.

In fact, if you are going to propose that, why not just have EVERY method be
defined like this:


int Match(params object[] theobjects)
{ }

int Average(params object[] theobjects)
{ }

int ListNames(params object[] theobjects)
{ }

Why even bother defining specific parameters? I'll tell you why - because it
gives the developer a firm/known interface to write to and gaurantees the
expected data types and number of parameters.

The point is, making a loosely-coupled interface like this is really, really
asking for trouble - from the fact that it's not self-documenting, which
leads to developer confusion and assumptions (which lead to bugs), to an
inherent bug of what if you change the underlying behaviour - but don't need
to change the interface? That can and will likely lead to bugs with
applications that consume this object.

In other words, if I give you an object I made it has:

string CalculateItems(params object[] theobjects)

You immediately need more information: "What do I pass in there? Does the
order matter? What kind of data types?". Versus if I gave you:

string CalculateItems (int[] ProductIDs)

Then it's very clear (read: "self-documenting") - that this takes an array
of ProductIDs.. You see?


This is just bad, bad form, please don't encourage people to do this!! If
you want loosely coupled, go write in VB6 and make everything a variant!!

I shall disagree with you. C# comes with even better support for variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

No, C# does not give you the ability have optional parameters like in

C++
or

VB. The best that you could do is function overloading, as Patrick
pointed
out.

--

Chris Rolon

This posting is provided "AS IS" with no warranties, and confers no rights.

Yes. Just overload the method.

public class MyClass
{
public void MyMethod(int x, int y)
{
...
}

public void MyMethod(int x)
{
MyMethod(x, 0);
}
}

Now you have a class with a "single" method, with two "options" of how
to call it.

Hope that helps.

Patrick Altman
<><


Juan wrote:
Thanks,
Juan.

 

[benben]

I swear to God that I NEVER used params in my formal projects. Yes you are
right, it leads to less elegant designs.

I thought the OP was requesting something like the ... operator in parameter
list so I flip though the C# book and found it.

ben

As has been pointed out, your use of params is inappropriate. C# does not
support default arguments, ala C++, which I believe is what Juan was asking.

--

Chris Rolon

This the most inappropriate use of params I've seen. I assumed there were
people that did this sort of thing, but this is the first time I've seen.

This is *NOT* how you should use params. Can you? Yes. Should you? No.

In fact, if you are going to propose that, why not just have EVERY

method

be
defined like this:


int Match(params object[] theobjects)
{ }

int Average(params object[] theobjects)
{ }

int ListNames(params object[] theobjects)
{ }

Why even bother defining specific parameters? I'll tell you why -

because

it
gives the developer a firm/known interface to write to and gaurantees the
expected data types and number of parameters.

The point is, making a loosely-coupled interface like this is really, really
asking for trouble - from the fact that it's not self-documenting, which
leads to developer confusion and assumptions (which lead to bugs), to an
inherent bug of what if you change the underlying behaviour - but don't need
to change the interface? That can and will likely lead to bugs with
applications that consume this object.

In other words, if I give you an object I made it has:

string CalculateItems(params object[] theobjects)

You immediately need more information: "What do I pass in there? Does the
order matter? What kind of data types?". Versus if I gave you:

string CalculateItems (int[] ProductIDs)

Then it's very clear (read: "self-documenting") - that this takes an array
of ProductIDs.. You see?


This is just bad, bad form, please don't encourage people to do this!! If
you want loosely coupled, go write in VB6 and make everything a variant!!

I shall disagree with you. C# comes with even better support for variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

No, C# does not give you the ability have optional parameters like in C++
or
VB. The best that you could do is function overloading, as Patrick
pointed
out.

--

Chris Rolon

This posting is provided "AS IS" with no warranties, and confers no
rights.

Yes. Just overload the method.

public class MyClass
{
public void MyMethod(int x, int y)
{
...
}

public void MyMethod(int x)
{
MyMethod(x, 0);
}
}

Now you have a class with a "single" method, with two "options" of how
to call it.

Hope that helps.

Patrick Altman
<><


Juan wrote:
Thanks,
Juan.

 

[benben]

This the most inappropriate use of params I've seen. I assumed there were
people that did this sort of thing, but this is the first time I've seen.

This is *NOT* how you should use params. Can you? Yes. Should you? No.

It is quite up to the implementor to decide the STYLE of the interface. In
those C days, we were too familiar with the printf() function, which exactly
takes variable parameters. They were designed and implemented and used, now
it is up to you to critique the design. But anyway, it is an option.

It is true that the overuse of params will lead to ugly designs.

In fact, if you are going to propose that, why not just have EVERY method be
defined like this:


int Match(params object[] theobjects)
{ }

int Average(params object[] theobjects)
{ }

int ListNames(params object[] theobjects)
{ }

Because they won't make sense. Take the Average example. Its semantics says
"calculate the average of a bundle of numbers", notice the "a bundle of
numbes", not necessarily "a bundle of objects, any objects".

Why even bother defining specific parameters? I'll tell you why - because it
gives the developer a firm/known interface to write to and gaurantees the
expected data types and number of parameters.

The point is, making a loosely-coupled interface like this is really, really
asking for trouble - from the fact that it's not self-documenting, which
leads to developer confusion and assumptions (which lead to bugs), to an
inherent bug of what if you change the underlying behaviour - but don't need
to change the interface? That can and will likely lead to bugs with
applications that consume this object.

In other words, if I give you an object I made it has:

string CalculateItems(params object[] theobjects)

You immediately need more information: "What do I pass in there? Does the
order matter? What kind of data types?". Versus if I gave you:

the params operator is only used to expand an array at call site. so instead
of passing an array as a single parameter, you now have a chance to pass in
a number of parameters to make the invocation look more natural.

notice I didn't simple use params object[], so "what kind of data types" are
answered in the declaration.

the order doesn't matter. Otherwise params won't be used here. What is the
difference of Average(1,2,3,4) and Average(2,4,1,3)?

string CalculateItems (int[] ProductIDs)

Then it's very clear (read: "self-documenting") - that this takes an array
of ProductIDs.. You see?


This is just bad, bad form, please don't encourage people to do this!! If
you want loosely coupled, go write in VB6 and make everything a variant!!

I don't encourage people to do this. I only treat the introduction of params
as a syntactic sugar. notice that:

string CalculateItems (params int[] ProductIDs)

is just compatible with

string CalculateItems (int[] ProductIDs)

as I said, the additional params operator is only to allow the caller to
pass in an array without openning a new line to declare the array.

I shall disagree with you. C# comes with even better support for variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

No, C# does not give you the ability have optional parameters like in

C++
or

VB. The best that you could do is function overloading, as Patrick
pointed
out.

--

Chris Rolon

This posting is provided "AS IS" with no warranties, and confers no rights.

Yes. Just overload the method.

public class MyClass
{
public void MyMethod(int x, int y)
{
...
}

public void MyMethod(int x)
{
MyMethod(x, 0);
}
}

Now you have a class with a "single" method, with two "options" of how
to call it.

Hope that helps.

Patrick Altman
<><


Juan wrote:
Thanks,
Juan.

 

[benben]

But after some afterthoughts I reason that there are situations when/where
the use of params could be appropriate.

It is only telling people, "hey, you can pass in an array, but if you are
too lazy to start a new line to declare that array, don't bother then, just
pass in the collection as separate parameters."

ben

I swear to God that I NEVER used params in my formal projects. Yes you are
right, it leads to less elegant designs.

I thought the OP was requesting something like the ... operator in parameter
list so I flip though the C# book and found it.

ben

As has been pointed out, your use of params is inappropriate. C# does not
support default arguments, ala C++, which I believe is what Juan was asking.

--

Chris Rolon

This the most inappropriate use of params I've seen. I assumed there were
people that did this sort of thing, but this is the first time I've seen.

This is *NOT* how you should use params. Can you? Yes. Should you? No.

In fact, if you are going to propose that, why not just have EVERY

method

be
defined like this:


int Match(params object[] theobjects)
{ }

int Average(params object[] theobjects)
{ }

int ListNames(params object[] theobjects)
{ }

Why even bother defining specific parameters? I'll tell you why -

because

it
gives the developer a firm/known interface to write to and gaurantees the
expected data types and number of parameters.

The point is, making a loosely-coupled interface like this is really, really
asking for trouble - from the fact that it's not self-documenting, which
leads to developer confusion and assumptions (which lead to bugs), to an
inherent bug of what if you change the underlying behaviour - but

don't
need

to change the interface? That can and will likely lead to bugs with
applications that consume this object.

In other words, if I give you an object I made it has:

string CalculateItems(params object[] theobjects)

You immediately need more information: "What do I pass in there? Does the
order matter? What kind of data types?". Versus if I gave you:

string CalculateItems (int[] ProductIDs)

Then it's very clear (read: "self-documenting") - that this takes an array
of ProductIDs.. You see?


This is just bad, bad form, please don't encourage people to do this!! If
you want loosely coupled, go write in VB6 and make everything a variant!!




I shall disagree with you. C# comes with even better support for variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

No, C# does not give you the ability have optional parameters like

in
C++

or
VB. The best that you could do is function overloading, as Patrick
pointed
out.

--

Chris Rolon

This posting is provided "AS IS" with no warranties, and confers no
rights.

Yes. Just overload the method.

public class MyClass
{
public void MyMethod(int x, int y)
{
...
}

public void MyMethod(int x)
{
MyMethod(x, 0);
}
}

Now you have a class with a "single" method, with two "options"

of
how

to call it.

Hope that helps.

Patrick Altman
<><


Juan wrote:
Thanks,
Juan.

 

[Sean Hederman]

String.Format comes leaping to mind as a good example of the use of params.

But after some afterthoughts I reason that there are situations when/where
the use of params could be appropriate.

It is only telling people, "hey, you can pass in an array, but if you are
too lazy to start a new line to declare that array, don't bother then,
just
pass in the collection as separate parameters."

ben

I swear to God that I NEVER used params in my formal projects. Yes you
are
right, it leads to less elegant designs.

I thought the OP was requesting something like the ... operator in parameter
list so I flip though the C# book and found it.

ben

As has been pointed out, your use of params is inappropriate. C# does not
support default arguments, ala C++, which I believe is what Juan was asking.

--

Chris Rolon


This the most inappropriate use of params I've seen. I assumed there were
people that did this sort of thing, but this is the first time I've seen.

This is *NOT* how you should use params. Can you? Yes. Should you?
No.

In fact, if you are going to propose that, why not just have EVERY method
be
defined like this:


int Match(params object[] theobjects)
{ }

int Average(params object[] theobjects)
{ }

int ListNames(params object[] theobjects)
{ }

Why even bother defining specific parameters? I'll tell you why - because
it
gives the developer a firm/known interface to write to and gaurantees the
expected data types and number of parameters.

The point is, making a loosely-coupled interface like this is really,
really
asking for trouble - from the fact that it's not self-documenting, which
leads to developer confusion and assumptions (which lead to bugs), to an
inherent bug of what if you change the underlying behaviour - but don't
need
to change the interface? That can and will likely lead to bugs with
applications that consume this object.

In other words, if I give you an object I made it has:

string CalculateItems(params object[] theobjects)

You immediately need more information: "What do I pass in there? Does the
order matter? What kind of data types?". Versus if I gave you:

string CalculateItems (int[] ProductIDs)

Then it's very clear (read: "self-documenting") - that this takes an array
of ProductIDs.. You see?


This is just bad, bad form, please don't encourage people to do
this!! If
you want loosely coupled, go write in VB6 and make everything a variant!!




I shall disagree with you. C# comes with even better support for variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

No, C# does not give you the ability have optional parameters like in
C++
or
VB. The best that you could do is function overloading, as Patrick
pointed
out.

--

Chris Rolon

This posting is provided "AS IS" with no warranties, and confers
no
rights.

Yes. Just overload the method.

public class MyClass
{
public void MyMethod(int x, int y)
{
...
}

public void MyMethod(int x)
{
MyMethod(x, 0);
}
}

Now you have a class with a "single" method, with two "options" of
how
to call it.

Hope that helps.

Patrick Altman
<><


Juan wrote:
Thanks,
Juan.

 

[RCS]

Well yeah, there are definitely appropriate places for using params, but in
user functions as described, I don't think it's proper. In places like
print() or string.Format() it does make sense, because you specifically
don't care what or how many parameters are sent in.

In most everything the average developer does, this is NOT the case - that's
all I'm saying. I'm not saying params is inherently bad, just the overuse of
them in regular code where a cleaner alternative is available.

This the most inappropriate use of params I've seen. I assumed there were
people that did this sort of thing, but this is the first time I've seen.

This is *NOT* how you should use params. Can you? Yes. Should you? No.

It is quite up to the implementor to decide the STYLE of the interface. In
those C days, we were too familiar with the printf() function, which
exactly
takes variable parameters. They were designed and implemented and used,
now
it is up to you to critique the design. But anyway, it is an option.

It is true that the overuse of params will lead to ugly designs.

In fact, if you are going to propose that, why not just have EVERY method be
defined like this:


int Match(params object[] theobjects)
{ }

int Average(params object[] theobjects)
{ }

int ListNames(params object[] theobjects)
{ }

Because they won't make sense. Take the Average example. Its semantics
says
"calculate the average of a bundle of numbers", notice the "a bundle of
numbes", not necessarily "a bundle of objects, any objects".

Why even bother defining specific parameters? I'll tell you why - because it
gives the developer a firm/known interface to write to and gaurantees the
expected data types and number of parameters.

The point is, making a loosely-coupled interface like this is really, really
asking for trouble - from the fact that it's not self-documenting, which
leads to developer confusion and assumptions (which lead to bugs), to an
inherent bug of what if you change the underlying behaviour - but don't need
to change the interface? That can and will likely lead to bugs with
applications that consume this object.

In other words, if I give you an object I made it has:

string CalculateItems(params object[] theobjects)

You immediately need more information: "What do I pass in there? Does the
order matter? What kind of data types?". Versus if I gave you:

the params operator is only used to expand an array at call site. so
instead
of passing an array as a single parameter, you now have a chance to pass
in
a number of parameters to make the invocation look more natural.

notice I didn't simple use params object[], so "what kind of data types"
are
answered in the declaration.

the order doesn't matter. Otherwise params won't be used here. What is the
difference of Average(1,2,3,4) and Average(2,4,1,3)?

string CalculateItems (int[] ProductIDs)

Then it's very clear (read: "self-documenting") - that this takes an
array
of ProductIDs.. You see?


This is just bad, bad form, please don't encourage people to do this!! If
you want loosely coupled, go write in VB6 and make everything a variant!!

I don't encourage people to do this. I only treat the introduction of
params
as a syntactic sugar. notice that:

string CalculateItems (params int[] ProductIDs)

is just compatible with

string CalculateItems (int[] ProductIDs)

as I said, the additional params operator is only to allow the caller to
pass in an array without openning a new line to declare the array.

I shall disagree with you. C# comes with even better support for
variable
number of arguments. It is the params keyword:

class Demo
{
double Average(params double[] numbers)
{
double total = 0;

foreach (double i in numbers)
{
total += i;
}

return total / numbers.Length;
}

int Match(double target, double error, params double[] candidates)
{
for (int i = 0; i < candidates.Length; ++i)
{
if (target - candiates <= error)
{
return i;
}
}

return -1;
}

string ListNames(params object[] objs)
{
string result = "";

foreach (object obj in objs)
{
result += obj.ToString();
result += "\r\n";
}

return result;
}

void Main()
{
double x = Average(1, 2, 3, 4); // yield 2.5
double y = Average(2, 3, 4, 5); // yield 3.5

// using array directly
double z = Average(double[] {3, 4, 5, 6}); // yield 4.5

int a = Match(3.1415926, 0.0001,
1.23456, 2.34567, 3.1416270, 4.7319032); // yield 2

// just another version
int b = Match(3.1415926, 0.0001,
double[]{1.23456, 2.34567, 3.1416270, 4.7319032});

string whatever("ben", 1, Color.Black, new MyClass());

// ...
}
}

No, C# does not give you the ability have optional parameters like in C++
or
VB. The best that you could do is function overloading, as Patrick
pointed
out.

--

Chris Rolon

This posting is provided "AS IS" with no warranties, and confers no
rights.

Yes. Just overload the method.

public class MyClass
{
public void MyMethod(int x, int y)
{
...
}

public void MyMethod(int x)
{
MyMethod(x, 0);
}
}

Now you have a class with a "single" method, with two "options" of how
to call it.

Hope that helps.

Patrick Altman
<><


Juan wrote:
Thanks,
Juan.