I'm writing a C# class library, and calling it from some Javascript code (technically Jscript.NET). I recently added some overloaded methods, and Javascript has trouble deciding which one to call, because it doesn't always know the types of its variables. I understand why this is happening in most cases, but I've got one example where I don't understand it.
Here are the overloaded method declarations in the C# class.
public virtual DeviceMessage RequestInUnits(
Command command,
int value,
UnitOfMeasure unit)
public virtual DeviceMessage RequestInUnits(
Command command,
Measurement measurement)
My application has a scripting feature that uses Jscript.NET. Here's some Javascript code that tries to call one of those methods on the C# class.
c.RequestInUnits(Command.MoveAbsolute, 0);
That's not a legal call, because the only method with two parameters expects a Measurement object as the second parameter. However, I would expect a type mismatch error. Instead, here's the compilation error I get.
More than one method or property matches this argument list at line 3 column 1
If I replace the 0 with "", then I get a type mismatch error. Why does Javascript think it can convert a number to an object? Why does it think it can coerce the types to more than one of those methods? Only one method takes two parameters.
This isn't a critical problem, but I don't like it when my library causes confusing error messages in calling code. I'd prefer to avoid that if I can.
This comes from this other question:
( How to build a method with unspecified amount of params en C# ).
But since it's a different question I had to ask it here
Supposing you have a method overloaded (this overload is allowed by the compiler):
private static string AddURISlash(params string[] remotePaths) //multiple strings
private static string AddURISlash(string remotePaths) //single string
How should you know which will be executed when only one parameter is recieved?
Is there a convention? or something that you have to test once?
Do I have to assume that since the only way to the single string method to be executed is to recieve a single string, that's the one that unequivocally be executed?
Thanks
How should you know which will be executed when only one parameter is recieved?
You read the specification, which explains how overload resolution is handled. From section 7.5.3.2, the relevant bullet point is:
Otherwise, if MP is applicable in its normal form and MQ has a params array and is applicable only in its expanded form, then MP is better than MQ.
So the version which doesn't require parameter array expansion (your single string version) is chosen at compile-time instead of the parameter array version.
I have the following problem:
public class MyType
{
public void method(int a, params object[] p){}
public void MyType()
{
method(5);
}
}
When I use a constructor everything is fine but when I try to use Activator.CreateInstance(MyType);
void Factory()
{
string componentPath = "MyType.dll";
Assembly component = Assembly.LoadFrom(componentPath);
Type myType= component.GetType("MyType");
Activator.CreateInstance(myType);
}
it fails with exception MyType.method(int32) is not found.
Important to notice that before I added params object[] p to method everything worked fine.
Thank You.
If you use methods with optional parameters or methods with params to pass a variable number of parameters, what you're doing is telling the compiler that when you CALL that method, will it please insert the necessary parameters for you? Optional parameters and params arrays are inserted in the calling code, not the called code. (See one of Eric Lipperts blog posts on optional parameters for some elaboration).
You're not using the C# compiler, and the Reflection API does not insert those parameters for you. For example, you can test this not just by reflection, but also by using two assemblies: Assembly A declares method(int X); it is compiled and the dll is referenced by assembly B. This assembly B contains a call to method(42). This works fine! Now, if you recompile assembly A and change the signature to method(int X, object bla=null) or method(int X, params object[] blas), then assembly B stops working - it contains an invalid call. Even so, the source code to assembly B is still OK - you just need to recompile.
Reflection simply happens not to do any of the optional parameter magic for you. It could, certainly - but it doesn't. While reflection doesn't support this, the DLR does, which brings me to the following...
Workaround: Try using the C# keyword dynamic, if possible (which for constructors, it isn't AFAIK) - that attempts to emulate C# calling conventions more closely and supports stuff like optional and named parameters. You may need to change the way your API is set up, however to use methods rather than constructors. It's hard to give more precise advice without seeing actual code.
Alternatively: You may be trying to load plugins, by the looks of it. .NET has some premade infrastructure to help you with this: Add-ins and Extensibility, which may make your task easier.
(Note: your example code is incomplete - I'm making a slight guess that method is in reality a constructor, but you should really post the actual code or at least a snippet that actually fails).
This won't work because you have to pass at least 2 parameters in your call to method(). The params modifier doesn't mean "optional".
This new feature is really convenient.
Lately I read the document of the "Microsoft All-In-One Code Framework", and it mentions that "Optional Parameters" is not CLS-Compliant.
So I tested it by using "Optional Parameters" in a public API, and turned on FxCop, then I compiled and FxCop did not complain about anything. At the mean while, FxCop did report a warning when I add an API that has uint as its return type.
So now I am confused, is "Optional Parameters" CLS-Compliant or not?
And what's the best way to find out whether a new language feature is CLS-Compliant or not?
Optional arguments are "sort-of" CLS-compliant. Methods with optional arguments are legal and can be successfully compiled with the CLSCompliant attribute, but callers of those methods don't necessarily need to take account of the default parameter values or the optional attribute. (In which case those methods would behave in exactly the same way as standard methods, requiring that all the arguments be stated explicitly at the call site.)
Methods that use default parameters
are allowed under the Common Language
Specification (CLS); however, the CLS
allows compilers to ignore the values
that are assigned to these parameters.
Code that is written for compilers
that ignore default parameter values
must explicitly provide arguments for
each default parameter. To maintain
the behavior that you want across
programming languages, methods that
use default parameters should be
replaced with method overloads that
provide the default parameters.
(Taken from the documentation for "CA1026: Default parameters should not be used".)
I interpret your question to be about Optional Arguments.
If so then I believe they are CLS-Compliant and you can check by using the CLSCompliant attribute:
using System;
[assembly: CLSCompliant(true)]
namespace ConsoleApplication1
{
public class Program
{
public static int Test(int val=42)
{
return val;
}
static void Main(string[] args)
{
System.Console.WriteLine(Test());
}
}
}
This compiles with no warnings.
Have a look at the CLS specs.
From page 41:
The vararg constraint can be included to indicate that all arguments past this point are optional. When
it appears, the calling convention shall be one that supports variable argument lists.
But the box right below says:
CLS Rule 15: The vararg constraint is not part of the CLS, and the only calling convention supported by the
CLS is the standard managed calling convention
I was watching Anders' talk about C# 4.0 and sneak preview of C# 5.0, and it got me thinking about when optional parameters are available in C# what is going to be the recommended way to declare methods that do not need all parameters specified?
For example something like the FileStream class has about fifteen different constructors which can be divided into logical 'families' e.g. the ones below from a string, the ones from an IntPtr and the ones from a SafeFileHandle.
FileStream(string,FileMode);
FileStream(string,FileMode,FileAccess);
FileStream(string,FileMode,FileAccess,FileShare);
FileStream(string,FileMode,FileAccess,FileShare,int);
FileStream(string,FileMode,FileAccess,FileShare,int,bool);
It seems to me that this type of pattern could be simplified by having three constructors instead, and using optional parameters for the ones that can be defaulted, which would make the different families of constructors more distinct [note: I know this change will not be made in the BCL, I'm talking hypothetically for this type of situation].
What do you think? From C# 4.0 will it make more sense to make closely related groups of constructors and methods a single method with optional parameters, or is there a good reason to stick with the traditional many-overload mechanism?
I'd consider the following:
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?
I haven't checked how the defaults are going to work, but I'd assume that the default values will be baked into the calling code, much the same as references to const fields. That's usually okay - changes to a default value are pretty significant anyway - but those are the things to consider.
When a method overload normally performs the same thing with a different number of arguments then defaults will be used.
When a method overload performs a function differently based on its parameters then overloading will continue to be used.
I used optional back in my VB6 days and have since missed it, it will reduce a lot of XML comment duplication in C#.
I've been using Delphi with optional parameters forever. I've switched to using overloads instead.
Because when you go to create more overloads, you'll invariably conflict with an optional parameter form, and then you'll have to convert them to non-optional anyway.
And I like the notion that there's generally one super method, and the rest are simpler wrappers around that one.
I will definitely be using the optional parameters feature of 4.0. It gets rid of the ridiculous ...
public void M1( string foo, string bar )
{
// do that thang
}
public void M1( string foo )
{
M1( foo, "bar default" ); // I have always hated this line of code specifically
}
... and puts the values right where the caller can see them ...
public void M1( string foo, string bar = "bar default" )
{
// do that thang
}
Much more simple and much less error prone. I've actually seen this as a bug in the overload case ...
public void M1( string foo )
{
M2( foo, "bar default" ); // oops! I meant M1!
}
I have not played with the 4.0 complier yet, but I would not be shocked to learn that the complier simply emits the overloads for you.
Optional parameters are essentially a piece of metadata which directs a compiler that's processing a method call to insert appropriate defaults at the call site. By contrast, overloads provide a means by which a compiler can select one of a number of methods, some of which might supply default values themselves. Note that if one tries to call a method that specifies optional parameters from code written in a language which doesn't support them, the compiler will require that the "optional" parameters be specified, but since calling a method without specifying an optional parameter is equivalent to calling it with a parameter equal to the default value, there's no obstacle to such languages calling such methods.
A significant consequence of binding of optional parameters at the call site is that they will be assigned values based upon the version of the target code which is available to the compiler. If an assembly Foo has a method Boo(int) with a default value of 5, and assembly Bar contains a call to Foo.Boo(), the compiler will process that as a Foo.Boo(5). If the default value is changed to 6 and assembly Foo is recompiled, Bar will continue to call Foo.Boo(5) unless or until it is recompiled with that new version of Foo. One should thus avoid using optional parameters for things that might change.
It can be argued whether optional arguments or overloads should be used or not, but most importantly, each have their own area where they are irreplaceable.
Optional arguments, when used in combination with named arguments, are extremely useful when combined with some long-argument-lists-with-all-optionals of COM calls.
Overloads are extremely useful when method is able to operate on many different argument types (just one of examples), and does castings internally, for instance; you just feed it with any data type that makes sense (that is accepted by some existing overload). Can't beat that with optional arguments.
In many cases optional parameters are used to switch execution. For example:
decimal GetPrice(string productName, decimal discountPercentage = 0)
{
decimal basePrice = CalculateBasePrice(productName);
if (discountPercentage > 0)
return basePrice * (1 - discountPercentage / 100);
else
return basePrice;
}
Discount parameter here is used to feed the if-then-else statement. There is the polymorphism that wasn't recognized, and then it was implemented as an if-then-else statement. In such cases, it is much better to split the two control flows into two independent methods:
decimal GetPrice(string productName)
{
decimal basePrice = CalculateBasePrice(productName);
return basePrice;
}
decimal GetPrice(string productName, decimal discountPercentage)
{
if (discountPercentage <= 0)
throw new ArgumentException();
decimal basePrice = GetPrice(productName);
decimal discountedPrice = basePrice * (1 - discountPercentage / 100);
return discountedPrice;
}
In this way, we have even protected the class from receiving a call with zero discount. That call would mean that the caller thinks that there is the discount, but in fact there is no discount at all. Such misunderstanding can easily cause a bug.
In cases like this, I prefer not to have optional parameters, but to force the caller explicitly select the execution scenario that suits its current situation.
The situation is very similar to having parameters that can be null. That is equally bad idea when implementation boils to statements like if (x == null).
You can find detailed analysis on these links: Avoiding Optional Parameters and Avoiding Null Parameters
One caveat of optional parameters is versioning, where a refactor has unintended consequences. An example:
Initial code
public string HandleError(string message, bool silent=true, bool isCritical=true)
{
...
}
Assume this is one of many callers of the above method:
HandleError("Disk is full", false);
Here the event is not silent and is treated as critical.
Now let's say after a refactor we find that all errors prompt the user anyway, so we no longer need the silent flag. So we remove it.
After refactor
The former call still compiles, and let's say it slips through the refactor unchanged:
public string HandleError(string message, /*bool silent=true,*/ bool isCritical=true)
{
...
}
...
// Some other distant code file:
HandleError("Disk is full", false);
Now false will have an unintended effect, the event will no longer be treated as critical.
This could result in a subtle defect, since there will be no compile or runtime error (unlike some other caveats of optionals, such as this or this).
Note that there are many forms of this same problem. One other form is outlined here.
Note also that strictly using named parameters when calling the method will avoid the issue, such as like this: HandleError("Disk is full", silent:false). However, it may not be practical to assume that all other developers (or users of a public API) will do so.
For these reasons I would avoid using optional parameters in a public API (or even a public method if it might be used widely) unless there are other compelling considerations.
One of my favourites aspects of optional parameters is that you see what happens to your parameters if you do not provide them, even without going to the method definition. Visual Studio will simply show you the default value for the parameter when you type the method name. With an overload method you are stuck with either reading the documentation (if even available) or with directly navigating to the method's definition (if available) and to the method that the overload wraps.
In particular: the documentation effort may increase rapidly with the amount of overloads, and you will probably end up copying already existing comments from the existing overloads. This is quite annoying, as it does not produce any value and breaks the DRY-principle). On the other hand, with an optional parameter there's exactly one place where all the parameters are documented and you see their meaning as well as their default values while typing.
Last but not least, if you are the consumer of an API you may not even have the option of inspecting the implementation details (if you don't have the source code) and therefore have no chance to see to which super method the overloaded ones are wrapping. Thus you're stuck with reading the doc and hoping that all default values are listed there, but this is not always the case.
Of course, this is not an answer that handles all aspects, but I think it adds one which has not be covered so far.
I'm looking forward to optional parameters because it keeps what the defaults are closer to the method. So instead of dozens of lines for the overloads that just call the "expanded" method, you just define the method once and you can see what the optional parameters default to in the method signature. I'd rather look at:
public Rectangle (Point start = Point.Zero, int width, int height)
{
Start = start;
Width = width;
Height = height;
}
Instead of this:
public Rectangle (Point start, int width, int height)
{
Start = start;
Width = width;
Height = height;
}
public Rectangle (int width, int height) :
this (Point.Zero, width, height)
{
}
Obviously this example is really simple but the case in the OP with 5 overloads, things can get crowded real quick.
While they are (supposedly?) two conceptually equivalent ways available for you to model your API from scratch, they unfortunately have some subtle difference when you need to consider runtime backward compatibility for your old clients in the wild. My colleague (thanks Brent!) pointed me to this wonderful post: Versioning issues with optional arguments. Some quote from it:
The reason that optional parameters were introduced to C# 4 in the
first place was to support COM interop. That’s it. And now, we’re
learning about the full implications of this fact. If you have a
method with optional parameters, you can never add an overload with
additional optional parameters out of fear of causing a compile-time
breaking change. And you can never remove an existing overload, as
this has always been a runtime breaking change. You pretty much need
to treat it like an interface. Your only recourse in this case is to
write a new method with a new name. So be aware of this if you plan to
use optional arguments in your APIs.
To add a no-brainer when to use an overload instead of optionals:
Whenever you have a number of parameters that only make sense together, do not introduce optionals on them.
Or more generally, whenever your method signatures enable usage patterns which don't make sense, restrict the number of permutations of possible calls. E.g., by using overloads instead of optionals (this rule also holds true when you have several parameters of the same datatype, by the way; here, devices like factory methods or custom data types can help).
Example:
enum Match {
Regex,
Wildcard,
ContainsString,
}
// Don't: This way, Enumerate() can be called in a way
// which does not make sense:
IEnumerable<string> Enumerate(string searchPattern = null,
Match match = Match.Regex,
SearchOption searchOption = SearchOption.TopDirectoryOnly);
// Better: Provide only overloads which cannot be mis-used:
IEnumerable<string> Enumerate(SearchOption searchOption = SearchOption.TopDirectoryOnly);
IEnumerable<string> Enumerate(string searchPattern, Match match,
SearchOption searchOption = SearchOption.TopDirectoryOnly);
Both Optional parameter , Method overload have there own advantage or disadvantage.it depends on your preference to choose between them.
Optional Parameter:
available only in .Net 4.0.
optional parameter reduce your code size.
You can't define out and ref parameter
overloaded methods:
You can Define Out and ref parameters.
Code size will increase but overloaded method's are easy to understand.