I've begun to notice at times when I'm making method calls in C# that the names of the parameters for the method I'm calling will show up in the intellisense list appended with a colon, and that I can then format the method call thusly:
MethodCall(parameter1:value1, parameter2:value2);
Is this a new language feature? It reminds me of the way you can call stored procedures in SQL and specify parameter names like so:
spDoSomeStuff #param1 = 1, #param2 = 'other param'
Is this a similar feature? If so, to what end? If not, what is it and what is it to be used for.
It's a new feature. See here: http://msdn.microsoft.com/en-us/library/dd264739.aspx
Named parameters are standard in ObjectiveC for instance. It takes some time to get used to them but they are a good thing. Only from looking you can tell what a parameter is meant for.
It is worth mentioning, unlike optional parameters, you can skip certain arguments and pass only the parameters you are interested in.
public void Example(int required, string StrVal = "default", int IntVal = 0)
{
// ...
}
public void Test()
{
// This gives compiler error
// Example(1, 10);
// This works
Example(1, IntVal:10);
}
Named parameters allow you explicitly set the value of arguments in a custom order independent of the signature. Method signatures are defined by the argument types, ie, Foo( int i, bool b ), which will only accept arguments of type int and bool in that order. Named arguments allow you to pass b first and i second.
Scott Gu has introduced this new feature in his blog:
Optional Parameters and Named Arguments in C# 4
It's the Named and Optional Parameters that came in with C# 4.
Related
I would like to be able to do the following:
Func<int,bool> tryMethodFunc = TryMethod;
Where TryMethod has a signature like:
bool TryMethod(int value, int value2 = 0, double value3 = 100.0)
I'm not opposed to breaking the method up into a curried format but that would be more work if there is a way to do this without that.
Optional parameters is a language feature, the compiler is responsible for translating the calls to methods with optional parameters to full call with values.
Look at this simple piece of code below,
public void GeneralMethod()
{
TestMethod(6);
}
public bool TestMethod(int a, int b = 8)
{
return true;
}
When you disassemble these methods, you will see that the C# compiler actually replaced the call to TestMethod with one parameter to a call with both the parameters. The screen shot from ildasm proves that,
Now, Coming to current problem, the line of code in question is trying to bind a Func with a method that has optional parameters. If C# compiler have to handle this, it has to ensure that the Func some knows the default values. While this could have been achieved by compiler, it completely defeats the purpose of Func.
Purpose of Func is to provides a way to store anonymous methods in a generalized and simple way." reference
Another similar question in stackoverflow can be found here
#Chris Sinclair's solution works around this by creating an anonymous method that takes one parameter and calls the TryMethod from the body of this anonymous method.
I got this assignment which to declare a method like this...
public List<Contact> GetLastContacts([int count = 20])
{
return this._entities.ContactsSet.ToList();
}
What I don't understand and can't find info about is [int count = 20] as parameter...
Anyone got an explanation on what they mean?
/Best regards!
int count = 20 in a parameter declares it as a default value for the parameter. It makes the parameter optional for callers (or rather look optional for callers).
So, in a method calling it you can do:
var contacts = GetLastContacts(); // Will compile to GetLastContacts(20)
Or, to use a value to override the default:
var contacts = GetLastContacts(35);
See Named and Optional arguments on MSDN.
public List<Contact> GetLastContacts(int count = 20) (no []) means the method has an int parameter called count, but that the parameter is optional, and if the caller leaves it out and just calls GetLastContacts() the default value for count is 20.
The square brackets are incorrect in C# code, but they can appear in documentation, tooltips etc. as an indication that the parameter is optional.
I guess this might be a combination of two ways to write "optional parameter". In C#, you can define a method with optional arguments if you specify a default argument value with "assignment" like
public List<Contact> GetLastContacts(int count = 20)
You can then either call
GetLastContacts(count)
to specify the count, or
GetLastContacts()
which uses the default value of 20.
The usage of [ ] in your code might be POSIX standardized way to write optional parameters, which has no reason to be there at all as it's not supported by C# language nor its documentation standards.
Can I have two same function name with same parameters but different meaning.
For example:
public void test(string name)
public void test(string age)
Thank you.
No, you can't. The signature is not different - it doesn't matter what the parameter names are.
Methods are declared in a class or struct by specifying the access level such as public or private, optional modifiers such as abstract or sealed, the return value, the name of the method, and any method parameters. These parts together are the signature of the method.
http://msdn.microsoft.com/en-us/library/ms173114.aspx
Like a few other answers have stated, consider the type of data you're taking in. Name is indeed a typical string, but does age have to be? If you allow it to be a - for example - int then you can overload your method as you wish.
No, you cannot overload on a return type or a parameter name. Unlike some other languages (most notably, Objective C1) parameter name is not part of the signature of your function.
The signature of a method consists of the name of the method and the type and kind (value, reference, or output) of each of its formal parameters, considered in the order left to right. The signature of a method specifically does not include the return type, nor does it include the params modifier that may be specified for the right-most parameter.
1 even there it's not exactly the parameter name that becomes part of the selector.
You can have static and non-static methods with the same name, but different parameters following the same rules as method overloading, they just can't have exactly the same signature.
No.
Signatures and Overloading
If you need a method with different meaning why won't you create a method with a different name? It would be confusing to use the same method name for different things on the same object.
You could mix together these methods using optional parameters and default values:
public void test(string name = null, string age = null)
{
if (name != null)
{
// Do something
}
else if (age != null)
{
// Do something else
}
}
And you could call this method like that:
test(name: "John");
test(age: "30");
Not very clean, but still useable.
No - the compiler throws an error because compiler use parameters to detemine which method to call, not the return type.
NO.
An OVERLOADED FUNCTION must have different SIGNATURE.
i.e.- arguments should be different, either in terms of number of arguments or order of different datatypes arguments.
I am working on my own command line arguments parser and after reading dozens of articles regarding method overloading I am still not certain if I am doing it right.
Am I getting any benefit from overloading methods this way? I know I could just write the entire thing in a single method (with default value parameters) by branching, but I'm experimenting overloads at the moment and I would like to know whether to continue on this path or not.
public static class MyParsers
{
private static List<string> args;
static MyParsers()
{
args = Environment.GetCommandLineArgs().ToList();
}
public static List<string> ParseOptions()
{
return ParseOptions(false);
}
public static List<string> ParseOptions(bool toLowercase)
{
// DEBUG: Change command line arguments here.
var arguments = args;
return !toLowercase
? arguments
: arguments.MyExtToLower();
}
public static bool OptionExists(string option)
{
return OptionExists(option, false);
}
public static bool OptionExists(string option, bool toLowercase)
{
var list = ParseOptions(toLowercase);
for (var i = 1; i < list.Count; i++)
{
if (list[i].StartsWith(option)) return true;
}
return false;
}
}
Yes that is the correct way to use overloads.
One thing to note about default parameters.
If you have two assemblies, A and B, A calls the function in B.
If you change the default in B:
using default values for parameters you need to recompile both assembly A and B for this change to take effect
using overloads you only need to recompile B.
This is because for default parameters, at compile time the compiler inserts the default values.
Yes, that's fine.
As you already know, you could also use optional parameters with default values, if your overloads only call another method with a default value (this would reduce the number of line of code).
Yep, this is how overloads work.
But a side-node:
Do you need your code to be used from languages which don't support
optional parameters? If so, consider including the overloads.
Do you have any members on your team who violently oppose optional parameters? (Sometimes it's easier to live with a decision
you don't like than to argue the case.)
Are you confident that your defaults won't change between builds of your code, or if they might, will your callers be okay with that?
Source: Should you declare methods using overloads or optional parameters in C# 4.0?
The "problem" with optional parameters is that if the default value is changed in some future version X of your assembly A then any client assemblies C that reference A will need to be recompiled in order to "see" the change -- loading an updated version of A will cause them to call the new methods with the old default values.
If this is not a potential problem then using optional parameters is more convenient. The equivalent version that emulates optional parameters using multiple overloads does not have this issue because in that case the default value is baked into assembly A instead of into C.
I think your style of overloading is fine.
If you thought you might have loads of different parsing arguments (ToUpperCase etc)
rather than have one class with lots of overloaded methods you might consider using object inheritance and have a LowerCaseParser, CamelCaseParser etc...
This isn't a question on proper coding practice, I'm just working through the semantics.
lets say I have the following constructors...
public FooClass(string name = "theFoo")
{ fooName = name; }
public FooClass(string name, int num = 7, bool boo = true) : this(name)
{ fooNum = num; fooBool = boo; }
is it possible to use named arguments thusly...?
FooClass foo1 = new FooClass(num:1);
// where I'm only passing one named argument, relying on the optionals to take care of the rest
or call the constructor FooClass(string, int, bool) with no arguments? as in...
FooClass foo2 = new FooClass();
Use of named and optional arguments affects overload resolution in the following ways:
A method, indexer, or constructor is a candidate for execution if each of its parameters either is optional or corresponds, by name or by position, to a single argument in the calling statement, and that argument can be converted to the type of the parameter.
If more than one candidate is found, overload resolution rules for preferred conversions are applied to the arguments that are explicitly specified. Omitted arguments for optional parameters are ignored.
If two candidates are judged to be equally good, preference goes to a candidate that does not have optional parameters for which arguments were omitted in the call. This is a consequence of a general preference in overload resolution for candidates that have fewer parameters.
http://msdn.microsoft.com/en-us/library/dd264739.aspx
Optional parameters are defined at the end of the parameter list, after any required parameters. If the caller provides an argument for any one of a succession of optional parameters, it must provide arguments for all preceding optional parameters. Comma-separated gaps in the argument list are not supported.
Also,
A named argument can follow positional arguments, as shown here.
CalculateBMI(123, height: 64);
However, a positional argument cannot follow a named argument. The following statement causes a compiler error.
//CalculateBMI(weight: 123, 64);