Methods, Named Parameters

  • Thread starter Thread starter Peter Hardy
  • Start date Start date
P

Peter Hardy

Hi Guys,

Can I use named parameters in C# Methods. i.e doFoo(fname="do",
lname="Foo");

Cheers, Pete
 
Peter,

Those arent named parameters (all parameters have a name, no?). Rather,
you would create overloads, like this:

public void doFoo()
{
// Call the overload.
doFoo("do");
}

public void doFoo(string fname)
{
// Call the overload
doFoo(fname, "Foo");
}

public void doFoo(string fname, string lname)
{
// Do something here.
}

Hope this helps.
 
Hi Nicholas,

In VB and in SQL, these are called named parameters.

Peter: I do not believe that this construct is a feature of the C# language.
This would require that all parameters that you didn't provide would have a
default value assigned to them, and C# provides no simple way for a
developer to indicate the default values that should be assigned to the
missing parameters. You can pass Type.Missing if you wish. However, the
more common approach is to do what Nicholas suggests: overload the method
signature with a new signature containing fewer parameters. However, if you
want to support combinations that involve multiple parameters of the same
type... you can't.

VB.NET does not have this problem. It has support for named parameters. Of
course, SQL does too.

References:
http://dotnetjunkies.com/WebLog/petergekko/archive/2003/10/22/2778.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlmag01/html/namedparameters.asp

HTH,
--- Nick

Nicholas Paldino said:
Peter,

Those arent named parameters (all parameters have a name, no?). Rather,
you would create overloads, like this:

public void doFoo()
{
// Call the overload.
doFoo("do");
}

public void doFoo(string fname)
{
// Call the overload
doFoo(fname, "Foo");
}

public void doFoo(string fname, string lname)
{
// Do something here.
}

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter Hardy said:
Hi Guys,

Can I use named parameters in C# Methods. i.e doFoo(fname="do",
lname="Foo");

Cheers, Pete
Click to expand...
Click to expand...
 
Hi Peter,

Nop, C# does not support named parameters, only "positional" parameters.

Cheers,
 
Hi,


I think that what he is refering is to have the opportunity to change the
order of the parameters and that the compiler reorder them based on the name
Ex::
void Method( string firstName, string lastName){}

You could do this
Method( lastName="xxx" , firstName="...." )

and the compiler would reorder the parameters at compiling time.

I know that some language support this, but I cannot remember which one

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation


Nicholas Paldino said:
Peter,

Those arent named parameters (all parameters have a name, no?).
Rather, you would create overloads, like this:

public void doFoo()
{
// Call the overload.
doFoo("do");
}

public void doFoo(string fname)
{
// Call the overload
doFoo(fname, "Foo");
}

public void doFoo(string fname, string lname)
{
// Do something here.
}

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter Hardy said:
Hi Guys,

Can I use named parameters in C# Methods. i.e doFoo(fname="do",
lname="Foo");

Cheers, Pete
Click to expand...
Click to expand...
 
Nick,

Named parameters is a foolish name, since they all have a name =)

Anyways, you can't pass Type.Missing unless the parameter is of type
object (and you shouldn't be declaring these parameters as type object if
they are really only a type of something else), because it is of type object
(or rather, returned as type object).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nick Malik said:
Hi Nicholas,

In VB and in SQL, these are called named parameters.

Peter: I do not believe that this construct is a feature of the C#
language.
This would require that all parameters that you didn't provide would have
a
default value assigned to them, and C# provides no simple way for a
developer to indicate the default values that should be assigned to the
missing parameters. You can pass Type.Missing if you wish. However, the
more common approach is to do what Nicholas suggests: overload the method
signature with a new signature containing fewer parameters. However, if
you
want to support combinations that involve multiple parameters of the same
type... you can't.

VB.NET does not have this problem. It has support for named parameters.
Of
course, SQL does too.

References:
http://dotnetjunkies.com/WebLog/petergekko/archive/2003/10/22/2778.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlmag01/html/namedparameters.asp

HTH,
--- Nick

in
message news:[email protected]...
Peter,

Those arent named parameters (all parameters have a name, no?). Rather,
you would create overloads, like this:

public void doFoo()
{
// Call the overload.
doFoo("do");
}

public void doFoo(string fname)
{
// Call the overload
doFoo(fname, "Foo");
}

public void doFoo(string fname, string lname)
{
// Do something here.
}

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Peter Hardy said:
Hi Guys,

Can I use named parameters in C# Methods. i.e doFoo(fname="do",
lname="Foo");

Cheers, Pete
Click to expand...
Click to expand...
Click to expand...
 
Hi Guyz,

Thanks for the feedback. I find named parameters (hey, I don't choose the
lingo) to be a useful way to document code.

For example, calling

ticket = new FormsAuthenticationTicket
(
version = 1,
name = txtUserName.Text,
issueDate = DateTime.Now,
expiration = DateTime.Now.AddMinutes(30),
isPersistant = false,
userData = "Users",
cookiePath = FormsAuthentication.FormsCookiePath
);

says a lot more to anyone reading the code than

ticket = new FormsAuthenticationTicket
(
1,
txtUserName.Text,
DateTime.Now,
DateTime.Now.AddMinutes(30),
false,
"Users",
FormsAuthentication.FormsCookiePath
);

I have this sinking feeling I'm gonna have to learn Visual Basic now ... And
just before Christmas too :(

Cheers Pete
 
Peter Hardy said:
Hi Guyz,

Thanks for the feedback. I find named parameters (hey, I don't choose the
lingo) to be a useful way to document code.

For example, calling

ticket = new FormsAuthenticationTicket
(
version = 1,
name = txtUserName.Text,
issueDate = DateTime.Now,
expiration = DateTime.Now.AddMinutes(30),
isPersistant = false,
userData = "Users",
cookiePath = FormsAuthentication.FormsCookiePath
);

says a lot more to anyone reading the code than

ticket = new FormsAuthenticationTicket
(
1,
txtUserName.Text,
DateTime.Now,
DateTime.Now.AddMinutes(30),
false,
"Users",
FormsAuthentication.FormsCookiePath
);

I have this sinking feeling I'm gonna have to learn Visual Basic now ...
And
just before Christmas too :(
Click to expand...

Out of curiosity, do you have any other reasons for liking them? The IDE
really kills off any need to use named parameters in this case, IMHO.
 
Out of curiosity, do you have any other reasons for liking them? The IDE
really kills off any need to use named parameters in this case, IMHO.
Click to expand...

Alternatively, for actually just reading code, it would be better not
to use a constructor which takes hundreds of parameters - instead, use
properties. If the properties shouldn't be changed after construction,
create a separate class encapsulating the "configuration", and pass
that in as an argument to the constructor.
 
Sure, check out COM interop. You'll soon see the problems that come from not
having named / default parameters. (Hint: I don't like typing!)

Cheers, Pete
 
If I follow your example my code will look as follows:

ticket = new FormsAuthenticationTicket();
ticket.Version = 1;
ticket.Name = txtUserName.Text;
ticket.IsPersistent = false;
ticket.IssueDate = DateTime.Now;
ticket.Expiration = DateTime.Now.AddMinutes(30);
ticket.UserData = "Users";
ticket.CookiePath = FormsAuthentication.FormsCookiePath;

Unfortunately, FormsAuthenticationTicket (and I suspect many other .Net
classes) doesn't provide and empty constructor.

This means I have to write the code as follows:

// param1 = name, param2 = isPersistant, param3 = duration
ticket = new FormsAuthenticationTicket(txtUserName.Text, false, 30);
ticket.Version = 1;
ticket.IssueDate = DateTime.Now;
ticket.UserData = "Users";
ticket.CookiePath = FormsAuthentication.FormsCookiePath;

Its not great but hey, I can read it on the train without needing access to
the api. But there's still a problem - it doesn't work. Once the class has
been created, its properties are read only which mean I can't set them. This
leaves me with two options 1) Provide a comment before the constructor
listing parameters or 2) create a seperate and sensibly named variable for
each parameter and provide them to the constructor. You can see the
disadvantages with both approaches. If anyone can think of a nicer way to
write the aboce code so its a little cleared I'd love to see it.

I know I must seem like a pedant but named parameters are available in
SmallTalk and Visual Basic but not in C# and I can't for the life of me
think why.

Cheers, Pete
 
Peter Hardy said:
Sure, check out COM interop. You'll soon see the problems that come from
not
having named / default parameters. (Hint: I don't like typing!)
Click to expand...

Named parameters is highly seperate from default\optional parameters. While
one may add features to the other, you would be quite capable of using named
parameters without the horrific default\optional parameter issue(just think,
COM would have been so nice if they had just left that idea out).
 
I know I must seem like a pedant but named parameters are available in
SmallTalk and Visual Basic but not in C# and I can't for the life of me
think why.
Click to expand...

The simple answer? Its not syntactially simple.

lname="Foo" is a valid assignment expression, it resolves to "Foo". If there
is a local with the name "lname" and a parameter with the name "lname", how
is the compiler to determine which you actually mean? The compiler could
guess, but that would be rather unsatisfactory, I would think.

The only feasible way to support it would be to add special syntax, however,
that would break consistency in the langauge, especially since the named
parameter like property setter syntax in attributes uses the name=value
method, although that is syntactically unambigious, unlike normal method
calls.
 
Wouldn't the complier know that lname=foo was a named parameter by virtue of
the fact that it's included in the method call? and the compiler would now
in advance that lname is a valid parameter name from the signature of the
method being called?

I hope you don't mind me following this thread, its just I suspect there is
a gap in my understanding and I'd like to fill it.

Cheers, Pete
 
Please ignore my last message, after a bit of thinking (and a mince pie) I
understand what your saying.

Forgive me, I'm in mourning for a feature that was never even there <grin>

Cheers, Pete
 
For example, calling
What about

ticket = new FormsAuthenticationTicket
(
1, // version
txtUserName.Text, // name
DateTime.Now, // issueDate
DateTime.Now.AddMinutes(30), // expiration
false, // isPersistant
"Users", // userData
FormsAuthentication.FormsCookiePath // userData
);

??
 
Hi,

No always and not for sure, what if you select weirds or not explicit names
for the parameters, then you get nothing from it.

AFAIK the only language that supported this was VB IIRC, and frankly I
never saw it used extensely.

Cheers,
 
Hi,


Daniel means that the expression var_a ="foo" may be interpreted of two
forms :

1- Assign "foo" to the variable var and then pass the variable var as the
parameter , this was something that VB did not have, you could not do
something like var_a = var_b = "foo" IIRC.

2- assign "foo" to the parameter var_a


the compiler has no idea which one you want to use

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
 
yeah, thats what i'm doing now. doesn't feel so neat cos I have to read it
right to left but am happy enough. Thanks for the help guys, really do
appreciate it

Cheers, Pete
 
Back
Top