Does C#2.0 support optional parameters like VB.NET:
Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
-
-
Re: Dose C#2.0 support optional parameters
see the params keyword for similar functionality
ad wrote:[color=blue]
> Does C#2.0 support optional parameters like VB.NET:
> Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
>
>[/color]
-
Re: Dose C#2.0 support optional parameters
I have seen it:
The params keyword lets you specify a method parameter that takes an
argument where the number of arguments is variable.
But it is different from optional parameters of VB.Net
"wbekker" <w.bekker@REMOV EequanimityTHIS dotnl>
???????:42b685b c$0$21527$e4fe5 14c@news.xs4all .nl...[color=blue]
> see the params keyword for similar functionality
>
> ad wrote:[color=green]
> > Does C#2.0 support optional parameters like VB.NET:
> > Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
> >
> >[/color][/color]
Comment
-
Re: Dose C#2.0 support optional parameters
Otherwise i'm afraid you are stuck with this kind of construction:
public void MyFunction(bool isCenter)
{
//place code here
}
public void MyFunction()
{
MyFunction(fals e);
}
Ward
ad wrote:[color=blue]
> I have seen it:
> The params keyword lets you specify a method parameter that takes an
> argument where the number of arguments is variable.
>
> But it is different from optional parameters of VB.Net
>
>
> "wbekker" <w.bekker@REMOV EequanimityTHIS dotnl>
> ???????:42b685b c$0$21527$e4fe5 14c@news.xs4all .nl...
>[color=green]
>>see the params keyword for similar functionality
>>
>>ad wrote:
>>[color=darkred]
>>>Does C#2.0 support optional parameters like VB.NET:
>>> Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
>>>
>>>[/color][/color]
>
>
>[/color]
Comment
-
Re: Dose C#2.0 support optional parameters
ad wrote:[color=blue]
> Does C#2.0 support optional parameters like VB.NET:
> Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
>
>[/color]
I certainly hope not ;)
JB
Comment
-
Re: Dose C#2.0 support optional parameters
Why,
Is there some drawback about optional parameters?
Optional parameter is supported by Delphi(Object Pascal) and VB.NET
Why C# ?[color=blue]
> I certainly hope not ;)[/color]
"John B" <jbngspam@yahoo .com>
???????:42b751b c$0$18641$14726 298@news.sunsit e.dk...[color=blue]
> ad wrote:[color=green]
> > Does C#2.0 support optional parameters like VB.NET:
> > Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
> >
> >[/color]
> I certainly hope not ;)
>
> JB[/color]
Comment
-
Re: Dose C#2.0 support optional parameters
ad wrote:[color=blue]
> Why,
> Is there some drawback about optional parameters?
> Optional parameter is supported by Delphi(Object Pascal) and VB.NET
> Why C# ?
>[color=green]
>>I certainly hope not ;)[/color]
>[/color]
I cant recall seeing a case where I would consider optional parameters
to be *better than overloading.
To take your case below, we could refactor as:
public bool MyFunction()
{
return Myfunction(fals e)
}
public bool MyFunction(bool center)
{
//do the dance
}
JB
*better being defined as readibility, ease of use, etc..
[color=blue]
>
>
>
> "John B" <jbngspam@yahoo .com>
> ???????:42b751b c$0$18641$14726 298@news.sunsit e.dk...
>[color=green]
>>ad wrote:
>>[color=darkred]
>>>Does C#2.0 support optional parameters like VB.NET:
>>> Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
>>>
>>>[/color]
>>
>>I certainly hope not ;)
>>
>>JB[/color]
>
>
>[/color]
Comment
-
Re: Dose C#2.0 support optional parameters
Limit them to a minimum yes, but they still have their place. Consider this.
public void Show(params string[] message)
{
if (message.Length == 0)
{
Console.WriteLi ne("No message!");
return;
}
Console.WriteLi ne("Messages... ");
foreach (string s in message)
{
Console.WriteLi ne(s);
}
}
public void Show2()
{
Console.WriteLi ne("No message!");
}
public void Show2(string message)
{
Console.WriteLi ne("Messages... ");
Console.WriteLi ne(message);
}
public void Show2(string[] message)
{
Console.WriteLi ne("Messages... ");
foreach (string s in message)
{
Console.WriteLi ne(s);
}
}
Now in this scenario, where we want to pass 0 to many messages in a
parameter for overloading we have had to create 3 different type signatures
wheras using optional params we only need the one. Also note that the
overloading scenario would look even more clumsy if we did checking for zero
length arrays in there as well -since the behaviour of it at present is not
identical to the optional one. Also note for the Show2, if you want to pass
multiple strings, type checking forces you to pass an array, wheras the
optional Show method allows for a list (or an array).
e.g.
inst.Show2(new string[]{"one","two" });
inst.Show("one" ,"two"); //this I believe is the greatest benefit
to the optional parameters.
inst.Show(new string[]{"one","two" });
Br,
Mark.
"John B" <jbngspam@yahoo .com> wrote in message
news:42b775c3$0 $18648$14726298 @news.sunsite.d k...[color=blue]
> ad wrote:[color=green]
>> Why,
>> Is there some drawback about optional parameters?
>> Optional parameter is supported by Delphi(Object Pascal) and VB.NET
>> Why C# ?
>>[color=darkred]
>>>I certainly hope not ;)[/color]
>>[/color]
> I cant recall seeing a case where I would consider optional parameters to
> be *better than overloading.
>
> To take your case below, we could refactor as:
>
> public bool MyFunction()
> {
> return Myfunction(fals e)
> }
>
> public bool MyFunction(bool center)
> {
> //do the dance
> }
>
> JB
> *better being defined as readibility, ease of use, etc..
>[color=green]
>>
>>
>>
>> "John B" <jbngspam@yahoo .com>
>> ???????:42b751b c$0$18641$14726 298@news.sunsit e.dk...
>>[color=darkred]
>>>ad wrote:
>>>
>>>>Does C#2.0 support optional parameters like VB.NET:
>>>> Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
>>>>
>>>>
>>>
>>>I certainly hope not ;)
>>>
>>>JB[/color]
>>
>>[/color][/color]
Comment
-
Re: Dose C#2.0 support optional parameters
Mark Broadbent wrote:[color=blue]
> Limit them to a minimum yes, but they still have their place. Consider this.
>[/color]
They may well have their place but I have yet to come across a scenario
where I would need them.
Not being a real example to me I can only try and interpret what you are
trying to achieve (I understand the code but would need a real life
situation where it would be applicable to me) but I would possibly write
this as:
public void show()
{
show("No Message");
}
public void show(params string[] messages)
{
foreach(string message in messages)
{
show(message);
}
}
public void show(string message)
{
console.writeli ne(message);
}
If we really wanted the line:
..WriteLine("Me ssages...");
then I would probably put a private writeheader method which would be
called by the relevant methods.
JB :)
[color=blue]
> public void Show(params string[] message)
> {
> if (message.Length == 0)
> {
> Console.WriteLi ne("No message!");
> return;
> }
>
> Console.WriteLi ne("Messages... ");
> foreach (string s in message)
> {
> Console.WriteLi ne(s);
> }
> }
>
>
> public void Show2()
> {
> Console.WriteLi ne("No message!");
> }
> public void Show2(string message)
> {
> Console.WriteLi ne("Messages... ");
> Console.WriteLi ne(message);
> }
> public void Show2(string[] message)
> {
> Console.WriteLi ne("Messages... ");
> foreach (string s in message)
> {
> Console.WriteLi ne(s);
> }
> }
>
> Now in this scenario, where we want to pass 0 to many messages in a
> parameter for overloading we have had to create 3 different type signatures
> wheras using optional params we only need the one. Also note that the
> overloading scenario would look even more clumsy if we did checking for zero
> length arrays in there as well -since the behaviour of it at present is not
> identical to the optional one. Also note for the Show2, if you want to pass
> multiple strings, type checking forces you to pass an array, wheras the
> optional Show method allows for a list (or an array).
>
> e.g.
> inst.Show2(new string[]{"one","two" });
>
> inst.Show("one" ,"two"); //this I believe is the greatest benefit
> to the optional parameters.
> inst.Show(new string[]{"one","two" });
>
>
> Br,
>
> Mark.
>
>
> "John B" <jbngspam@yahoo .com> wrote in message
> news:42b775c3$0 $18648$14726298 @news.sunsite.d k...
>[color=green]
>>ad wrote:
>>[color=darkred]
>>>Why,
>>>Is there some drawback about optional parameters?
>>>Optional parameter is supported by Delphi(Object Pascal) and VB.NET
>>>Why C# ?
>>>
>>>
>>>>I certainly hope not ;)
>>>[/color]
>>I cant recall seeing a case where I would consider optional parameters to
>>be *better than overloading.
>>
>>To take your case below, we could refactor as:
>>
>>public bool MyFunction()
>>{
>>return Myfunction(fals e)
>>}
>>
>>public bool MyFunction(bool center)
>>{
>>//do the dance
>>}
>>
>>JB
>>*better being defined as readibility, ease of use, etc..
>>
>>[color=darkred]
>>>
>>>
>>>"John B" <jbngspam@yahoo .com>
>>>???????:42b7 51bc$0$18641$14 726298@news.sun site.dk...
>>>
>>>
>>>>ad wrote:
>>>>
>>>>
>>>>>Does C#2.0 support optional parameters like VB.NET:
>>>>> Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
>>>>>
>>>>>
>>>>
>>>>I certainly hope not ;)
>>>>
>>>>JB
>>>
>>>[/color][/color]
>[/color]
Comment
-
Re: Dose C#2.0 support optional parameters
I agree to an extent with what you say although I have still used them
occasionally.
Couple of points though ...
1. What if that extra "Messages.. ." line was something useful (and many
lines of code)?
1.a Firstly your version fails to account for passing an empty array into
that overload. i.e. The "No Message" message would not be printed from your
code.
1.b You mention this extra private method for the header, but have you
thought what it would do to the code? This would have to be called by each
overload apart from the first, which would mean that when the Show(array
sig) method calls the Show(string sig) method you'd get (if a 3 element
array was passed)...
Messages...
Messages...
.....
Messages...
.....
Messages...
....
2. I still fail to see any benefits to your code in this example over the
optional params. Or to put it another way, what benefit are we getting? If
you write your code so that it displays exactly the same functionality you
will see that it cannot be done as efficiently without using the optional
parameter.
3. Real world example or not, the behaviour that is demonstrated (namely the
fact that we can pass 0 to many arguments and handle it fine in a few lines
of code) can be applied to many many different scenarios.
....I'll give you one. I have a method which takes zero to many attributes
(objects) and adds them into an element object. I want to be able to have
the following to be possible.(apolo gies for any typos! but you get the
idea)..
Element e = new Element();
e.Add();
e.Add(new Attribute());
e.Add(new Attribute(), new Attribute());
e.Add(new Attribute[]{});
e.Add(new Attribute[]{new Attribute(), new Attribute});
4. What we have here is the same sort of argument that people say against
jumping execution e.g. GOTO. Those people say NEVER use it. Sometimes
though, certain things are more appropriate to certain scenarios and goto
and optional parameters definitely have a time and place.
I'll reiterate on thing though and that is to ONLY use them when appropriate
and that refactoring using overloads is most likely going to be appropriate
in 98% of the time.
Br,
Mark.
"John B" <jbngspam@yahoo .com> wrote in message
news:42b8995c$0 $18645$14726298 @news.sunsite.d k...[color=blue]
> Mark Broadbent wrote:[color=green]
>> Limit them to a minimum yes, but they still have their place. Consider
>> this.
>>[/color]
> They may well have their place but I have yet to come across a scenario
> where I would need them.
>
> Not being a real example to me I can only try and interpret what you are
> trying to achieve (I understand the code but would need a real life
> situation where it would be applicable to me) but I would possibly write
> this as:
>
> public void show()
> {
> show("No Message");
> }
>
> public void show(params string[] messages)
> {
> foreach(string message in messages)
> {
> show(message);
> }
> }
>
> public void show(string message)
> {
> console.writeli ne(message);
> }
>
>
> If we really wanted the line:
> ..WriteLine("Me ssages...");
>
> then I would probably put a private writeheader method which would be
> called by the relevant methods.
>
> JB :)
>
>[color=green]
>> public void Show(params string[] message)
>> {
>> if (message.Length == 0)
>> {
>> Console.WriteLi ne("No message!");
>> return;
>> }
>>
>> Console.WriteLi ne("Messages... ");
>> foreach (string s in message)
>> {
>> Console.WriteLi ne(s);
>> }
>> }
>>
>>
>> public void Show2()
>> {
>> Console.WriteLi ne("No message!");
>> }
>> public void Show2(string message)
>> {
>> Console.WriteLi ne("Messages... ");
>> Console.WriteLi ne(message);
>> }
>> public void Show2(string[] message)
>> {
>> Console.WriteLi ne("Messages... ");
>> foreach (string s in message)
>> {
>> Console.WriteLi ne(s);
>> }
>> }
>>
>> Now in this scenario, where we want to pass 0 to many messages in a
>> parameter for overloading we have had to create 3 different type
>> signatures wheras using optional params we only need the one. Also note
>> that the overloading scenario would look even more clumsy if we did
>> checking for zero length arrays in there as well -since the behaviour of
>> it at present is not identical to the optional one. Also note for the
>> Show2, if you want to pass multiple strings, type checking forces you to
>> pass an array, wheras the optional Show method allows for a list (or an
>> array).
>>
>> e.g.
>> inst.Show2(new string[]{"one","two" });
>>
>> inst.Show("one" ,"two"); //this I believe is the greatest
>> benefit to the optional parameters.
>> inst.Show(new string[]{"one","two" });
>>
>>
>> Br,
>>
>> Mark.
>>
>>
>> "John B" <jbngspam@yahoo .com> wrote in message
>> news:42b775c3$0 $18648$14726298 @news.sunsite.d k...
>>[color=darkred]
>>>ad wrote:
>>>
>>>>Why,
>>>>Is there some drawback about optional parameters?
>>>>Optional parameter is supported by Delphi(Object Pascal) and VB.NET
>>>>Why C# ?
>>>>
>>>>
>>>>>I certainly hope not ;)
>>>>
>>>I cant recall seeing a case where I would consider optional parameters to
>>>be *better than overloading.
>>>
>>>To take your case below, we could refactor as:
>>>
>>>public bool MyFunction()
>>>{
>>>return Myfunction(fals e)
>>>}
>>>
>>>public bool MyFunction(bool center)
>>>{
>>>//do the dance
>>>}
>>>
>>>JB
>>>*better being defined as readibility, ease of use, etc..
>>>
>>>
>>>>
>>>>
>>>>"John B" <jbngspam@yahoo .com>
>>>>???????:42b 751bc$0$18641$1 4726298@news.su nsite.dk...
>>>>
>>>>
>>>>>ad wrote:
>>>>>
>>>>>
>>>>>>Does C#2.0 support optional parameters like VB.NET:
>>>>>> Function MyFunction(Opti onal ByVal isCenter As Boolean = False)
>>>>>>
>>>>>>
>>>>>
>>>>>I certainly hope not ;)
>>>>>
>>>>>JB
>>>>
>>>>[/color]
>>[/color][/color]
Comment
-
Re: Dose C#2.0 support optional parameters
Mark Broadbent wrote:[color=blue]
> I agree to an extent with what you say although I have still used them
> occasionally.[/color]
I did not say that they were the root of all evil. What I did say and
stand by is that I have not come across a case where I thought not
having them was a major drawback. :)
[color=blue]
> Couple of points though ...
> 1. What if that extra "Messages.. ." line was something useful (and many
> lines of code)?[/color]
Still handled by the private header method.
[color=blue]
> 1.a Firstly your version fails to account for passing an empty array into
> that overload. i.e. The "No Message" message would not be printed from your
> code.
>[/color]
true, easily enough fixed by:
//public methods
public void WriteOutput(str ing message)
{
//since string is also nullable ;)
if(message == null || message == "") //an extrapolation to assume
that "" equals no message as well
{
WriteNoMessageH eader();
}
else
{
WriteMessageHea der();
Write(Message);
}
}
public void WriteOutput()
{
WriteNoMessageH eader();
}
public void WriteOutput(par ams string[] messages)
{
if(messages == null || messages.Length == 0)
{
WriteNoMessageH eader();
}
else
{
WriteMessageHea der();
foreach(string s in messages)
{
WriteMessage(s) ;
}
}
}
//private methods
private void Write(string message)
{
Console.WriteLi ne(message);
}
private void WriteNoMessageH eader()
{
Write("No Messages");
}
private void WriteMessageHea der()
{
Write("Messages ...");
}
[color=blue]
> 1.b You mention this extra private method for the header, but have you
> thought what it would do to the code? This would have to be called by each
> overload apart from the first, which would mean that when the Show(array
> sig) method calls the Show(string sig) method you'd get (if a 3 element
> array was passed)...
>
> Messages...
> Messages...
> ....
> Messages...
> ....
> Messages...
> ...
>
> 2. I still fail to see any benefits to your code in this example over the
> optional params. Or to put it another way, what benefit are we getting? If
> you write your code so that it displays exactly the same functionality you
> will see that it cannot be done as efficiently without using the optional
> parameter.
>
> 3. Real world example or not, the behaviour that is demonstrated (namely the
> fact that we can pass 0 to many arguments and handle it fine in a few lines
> of code) can be applied to many many different scenarios.
>
> ...I'll give you one. I have a method which takes zero to many attributes
> (objects) and adds them into an element object. I want to be able to have
> the following to be possible.(apolo gies for any typos! but you get the
> idea)..
>[/color]
Not being an example that has any context to me I can only speculate but
I would think that it would be able to be handled just as neatly (if not
more so;)) by overloading in the same style as my messages example.
[color=blue]
> Element e = new Element();
> e.Add();
> e.Add(new Attribute());
> e.Add(new Attribute(), new Attribute());
> e.Add(new Attribute[]{});
> e.Add(new Attribute[]{new Attribute(), new Attribute});
>[/color]
I dont think that this would be possible with optional in the vb6/vb.net
way.
It would instead be
.....
e.Add(,,new attribute[]{});
[color=blue]
>
> 4. What we have here is the same sort of argument that people say against
> jumping execution e.g. GOTO. Those people say NEVER use it. Sometimes
> though, certain things are more appropriate to certain scenarios and goto
> and optional parameters definitely have a time and place.
>[/color]
Ah, yes, the fanatics out there :)
I do concede that there are times when they might be appropriate but
have not come across an instance _myself_ so far.
[color=blue]
> I'll reiterate on thing though and that is to ONLY use them when appropriate
> and that refactoring using overloads is most likely going to be appropriate
> in 98% of the time.
>[/color]
Agreed, however, tools like optional params provide an easy way out of
hard thinking in a lot of cases and are therefore abused by lazy
programmers.
If everyone used them only when it was the _best_ solution then it would
be good. Since (IMO) they are mostly used in non appropriate situations
and to cater for vb6's lack of support for overloading I for one am
happy the are not catered for in c#.
Cheers
JB :)
<snip>
Comment
-
Re: Dose C#2.0 support optional parameters
Would this help - I'm not very good at this but gimme a chance:
public void WriteOutput(obj ect input)
{
System.Console. WriteLine("Mess ages...");
if (input is string[])
{
// Do string array stuff
//including checking for no message
}
else if (input is string)
{
// Do string stuff
// Including once again, checking for no message
}
else
{
// Do what you do to stupid users who pass silly params
}
}
That should let you use either your string array OR your string.. or a Haddock object if
you want without any overloading, optional parameters or jiggery pokery.
It just uses reflection instead :S But no one is perfect.
The thing with optional parameters vs. overloading is that neither side can win because
both sides have a valid argument. Lazy VB monkeys say optional is easier, anal C#
monkeys say overloading is more structured.
I'm a C# monkey - and was therefor appaled at the suggestion that a method signature
could be so contaminated... . but that's life :)
------------------------------------
Another unchecked rambeling brought to you by:
Oddball
joshua@bf#N0SP4 M#wd.co.uk
Comment
-
Re: Dose C#2.0 support optional parameters
Oddball wrote:[color=blue]
> Would this help - I'm not very good at this but gimme a chance:
>
> public void WriteOutput(obj ect input)
> {
> System.Console. WriteLine("Mess ages...");
>
> if (input is string[])
> {
> // Do string array stuff
> //including checking for no message
> }
> else if (input is string)
> {
> // Do string stuff
> // Including once again, checking for no message
> }
> else
> {
> // Do what you do to stupid users who pass silly params[/color]
throw new argumentoutofra ngeexception("O i peanut! Dont pass stupid
parameters :)"); //hehe[color=blue]
> }
> }
>
> That should let you use either your string array OR your string.. or a Haddock object if
> you want without any overloading, optional parameters or jiggery pokery.
>[/color]
Yeah, not what we want in this case as we do want to limit the types
that can be passed but does the job.
[color=blue]
> It just uses reflection instead :S But no one is perfect.
>
> The thing with optional parameters vs. overloading is that neither side can win because
> both sides have a valid argument. Lazy VB monkeys say optional is easier, anal C#
> monkeys say overloading is more structured.
>[/color]
Agreed.
[color=blue]
> I'm a C# monkey - and was therefor appaled at the suggestion that a method signature
> could be so contaminated... . but that's life :)
>[/color]
Me too (evolving (devolving probably according to some) vb6 monkey) :)
Of course they do have their place and would be valuable in some cases.
Doesnt mean I miss them or want them or would be happy if c# supported them.
I cannot _win_ this discussion, nor do I really want to, but if anyone
who queries this question reads this discussion, they might well think a
bit about why they think they need them and can maybe come to a "better"
solution. ("better" by my definition, one that does not need optional
params :-P)
JB[color=blue]
>
> ------------------------------------
>
> Another unchecked rambeling brought to you by:
>
> Oddball
> joshua@bf#N0SP4 M#wd.co.uk[/color]
Comment
-
Re: Dose C#2.0 support optional parameters
....and finally
John, even your overloaded solution uses the optional params statement
thereby contradicting your entire argument and making your code rewrite
pointless (also let me remind you of my original [nice compact and fully
functional] code)
public void Show(params string[] message){
if (message.Length == 0){
Console.WriteLi ne("No message!");
return;
}
Console.WriteLi ne("Messages... ");
foreach (string s in message) {
Console.WriteLi ne(s);
}
}
How on earth you can think that your refactored solution is an improvement
over this leaves me scratching my head. Even if you are relatively new to C#
you would surely see how horrible your refactored code is? Note the line in
your first post "*better being defined as readibility, ease of use, etc..",
well I disagree with every point in this sentence with regards to the
context of the examples I have given.
*Oddball* yeah fine but...
1. You are sacrificing the ability to have the compiler check the types
passed to the procedure. Why provide the ability to pass all types
(including Haddock objects :) when we only want strings and empty in this
example. Typechecking is there for a reason. It was interesting to note that
John didn't decide this was a retrograde step.
2. Testing the types within the method is *not* (as I'm sure you are aware)
an improvement over my code (in any respect e.g. speed size etc).
3. Your code fails to allow passing a list of strings e.g.
"like","thu s"
*Back to John*
I remember your line that moved me to action "I cant recall seeing a case
where I would consider optional parameters to be *better than overloading."
which suprisingly you still maintain.
When some posters make these throwaway comments, it puts novices on the
wrong track i.e. a blind belief that something is thus because they read it
somewhere.
That is how bad coding starts.
For instance I dislike the switch statement for a few reasons, but I'd never
say 'I've never seen a time when switch was preferable to using If's and
better structured code' because that would suggest to others that switch
shouldn't ever be used (and is also not entirely accurate). -And be honest
John that is essentially what you've been communicating with regards to
optional parameters.
This is probably going to be my last post in this thread (I hope), but if
you still are not convinced then try posting to this ng something like
'Optional params are a waste of time.I cant recall seeing a case where I
would consider optional parameters to be *better than overloading'.
Hopefully a few mvps will succeed in convincing you where I seem to have
failed.
Br,
Mark.
"John B" <jbngspam@yahoo .com> wrote in message
news:42ba18e3$0 $18644$14726298 @news.sunsite.d k...[color=blue]
> Oddball wrote:[color=green]
>> Would this help - I'm not very good at this but gimme a chance:
>>
>> public void WriteOutput(obj ect input)
>> {
>> System.Console. WriteLine("Mess ages...");
>>
>> if (input is string[])
>> {
>> // Do string array stuff
>> //including checking for no message
>> }
>> else if (input is string)
>> {
>> // Do string stuff
>> // Including once again, checking for no message
>> }
>> else
>> {
>> // Do what you do to stupid users who pass silly params[/color]
> throw new argumentoutofra ngeexception("O i peanut! Dont pass stupid
> parameters :)"); //hehe[color=green]
>> }
>> }
>>
>> That should let you use either your string array OR your string.. or a
>> Haddock object if you want without any overloading, optional parameters
>> or jiggery pokery.
>>[/color]
> Yeah, not what we want in this case as we do want to limit the types that
> can be passed but does the job.
>[color=green]
>> It just uses reflection instead :S But no one is perfect.
>>
>> The thing with optional parameters vs. overloading is that neither side
>> can win because both sides have a valid argument. Lazy VB monkeys say
>> optional is easier, anal C# monkeys say overloading is more structured.
>>[/color]
> Agreed.
>[color=green]
>> I'm a C# monkey - and was therefor appaled at the suggestion that a
>> method signature could be so contaminated... . but that's life :)
>>[/color]
> Me too (evolving (devolving probably according to some) vb6 monkey) :)
>
> Of course they do have their place and would be valuable in some cases.
> Doesnt mean I miss them or want them or would be happy if c# supported
> them.
> I cannot _win_ this discussion, nor do I really want to, but if anyone who
> queries this question reads this discussion, they might well think a bit
> about why they think they need them and can maybe come to a "better"
> solution. ("better" by my definition, one that does not need optional
> params :-P)
>
>
> JB[color=green]
>>
>> ------------------------------------
>>
>> Another unchecked rambeling brought to you by:
>>
>> Oddball
>> joshua@bf#N0SP4 M#wd.co.uk[/color][/color]
Comment
-
Re: Dose C#2.0 support optional parameters
Mark Broadbent wrote:
...HMM
I dont want to get into a flame war over this however I would like to
say that I dont like your condescending tone and IMO either your
comprehension of the discussion is lacking, my ability to express myself
clearly is lacking or we are arguing two different things. Therefore
this _will_ be my last post on the matter.
[color=blue]
> ...and finally
> John, even your overloaded solution uses the optional params statement[/color]
The point was to illustrate an easy/neat way to get around not having
optional parameters available.
But yes, I should have written it as
....Show(string[] message)...
[color=blue]
> thereby contradicting your entire argument and making your code rewrite
> pointless (also let me remind you of my original [nice compact and fully
> functional] code)
>
> public void Show(params string[] message){
> if (message.Length == 0){
> Console.WriteLi ne("No message!");
> return;
> }
> Console.WriteLi ne("Messages... ");
> foreach (string s in message) {
> Console.WriteLi ne(s);
> }
> }
>[/color]
[color=blue]
> How on earth you can think that your refactored solution is an improvement
> over this leaves me scratching my head.[/color]
OMG :(
The code I wrote was meant to illustrate an easy way to have the ability
for a method which takes zero, 1, 2, zero to many string parameters.
[color=blue]
> Even if you are relatively new to C#
> you would surely see how horrible your refactored code is?[/color]
Not what I would call nice, but I would not say horrible, matter of
opinion I suppose.
[color=blue]
> Note the line in
> your first post "*better being defined as readibility, ease of use, etc..",
> well I disagree with every point in this sentence with regards to the
> context of the examples I have given.
>
> *Oddball* yeah fine but...
> 1. You are sacrificing the ability to have the compiler check the types
> passed to the procedure. Why provide the ability to pass all types
> (including Haddock objects :) when we only want strings and empty in this
> example. Typechecking is there for a reason.[/color]
[color=blue]
> It was interesting to note that
> John didn't decide this was a retrograde step.[/color]
Maybe you missed or misread the line
"not what we want in this case as we do want to limit the types that can
be passed"
[color=blue]
> 2. Testing the types within the method is *not* (as I'm sure you are aware)
> an improvement over my code (in any respect e.g. speed size etc).
> 3. Your code fails to allow passing a list of strings e.g.
> "like","thu s"
>
> *Back to John*
> I remember your line that moved me to action "I cant recall seeing a case
> where I would consider optional parameters to be *better than overloading."
> which suprisingly you still maintain.[/color]
Gee, so you are saying I _could_ recall seeing a case where I would
consider optional parameters better than overloading?
You must know me better than myself, neat.
BTW, I do not consider academic examples as "cases" as I was
specifically referring to real life experience.
[color=blue]
> When some posters make these throwaway comments, it puts novices on the
> wrong track i.e. a blind belief that something is thus because they read it
> somewhere.[/color]
Did you miss the "I cant recall bit.... *better than overloading"?
This is totally different from saying "overloadin g is always better than
optional parameters." as you are implying that I am saying.
[color=blue]
> That is how bad coding starts.
> For instance I dislike the switch statement for a few reasons, but I'd never
> say 'I've never seen a time when switch was preferable to using If's and
> better structured code' because that would suggest to others that switch
> shouldn't ever be used (and is also not entirely accurate). -And be honest
> John that is essentially what you've been communicating with regards to
> optional parameters.
>[/color]
Maybe by your reading. Others, I cant answer for but this is _not_ what
I have been trying to communicate. (did you read the bit where I said
"Of course they do have their place and would be valuable in some cases."?)
[color=blue]
> This is probably going to be my last post in this thread (I hope), but if
> you still are not convinced then try posting to this ng something like
> 'Optional params are a waste of time.[/color]
Why would I post something like this when I have never taken this stance?
[color=blue]
> I cant recall seeing a case where I
> would consider optional parameters to be *better than overloading'.
> Hopefully a few mvps will succeed in convincing you where I seem to have
> failed.
>[/color]
Just to reiterate.
I have not come across a case where I have felt that optional parameters
would be better than overloading.
This does not mean that I consider optional parameters as the root of
all evil or an invaluable construct.
At the same time I do not miss them or consider c# to be any way lacking
without them.
Take care :)
JB
<here there be snippage>
Comment
Comment