Paul on Default Arguments

Paul Vick chimes in on default arguments.  He has some good points; I can believe the main problem with my example is one of generally bad API design.  But I think the technical issue of the default arguments being burned into the callsite still exists… Even though it is a gray area I think changing defaults, especially implementation in nature, is a right a library designer may need to preserve for herself.   For example, changing the default size capacity of ArrayList…

 

There is a bigger issue which Paul’s post makes me consider.  If we did allow default arguments what simple consistent rule would we use for deciding when to use one or the other?  If we moved away from the simple rule of “never use default arguments in a publicly exposed API” would we get into another debate like the ID one (or is Id)?

Published 30 November 03 08:33 by BradA

Comments

# Eric Newton said on December 1, 2003 9:17 AM:
I feel that default values are a neccesary evil given method overloading, i actually LIKE Vb's approach of adding the appropriate metadata that informs the developer of the actual value being passed to the "more specific" overload of the method. But the issue of Bad API design is very much the case here, since something as fluid as a Tax Rate should never be burned into a class library as a default value, period... Only things that would never truly impact program correctness, keyword: "CORRECTNESS", should be defaulted. Brad, you mention changing the default size capacity of the ArrayList, but I assert that since the capacity of the ArrayList could never affect the correctness of the routine, its a "safe default" value, but a value like TaxRate, or even worse, ExchangeRate which could change daily, should NEVER be burned into a library, this point we both agree upon. However, I would still frown on an overload passing in that default value... This has been another pet peeve of mine and most of what I've seen of the .NET Framework does this PROPERLY and I'm very happy on that note... All in all, perhaps the Sales tax example wasn't a good one ;-)
# David Nicholson said on December 1, 2003 6:25 PM:
By changing the default value you are changing the result returned by a particular method signature. This is no different from making some other code change that gives a different result for the same input, and shouldn't be done if you don't control all the code. I would think of the guidline as don't change a default value unless you can compile all callers. I think it highlights an implementation detail that wasn't obvious to me.
# Jeremy said on December 3, 2003 9:44 AM:
Defaults are already used all over the place in .NET, and we should follow the pattern already established. For instance, if I write a function (say it's a member of the string class) like so: public string PadLeft(int n, char c=' ') The compiler should automatically do what .NET functions are already doing. It should compile one version of the function as written, and a second (overloaded) version of the function which just calls the function you already wrote: PadLeft(n, ' '). The JIT can optimize at runtime. Should the default change, the user code will call the function with the new changed default, which is exactly what you would expect if we changed the default value in the overloaded version. We're already doinfg this, so what's the big deal? Here's another example:: public string IndexOf(string value, int start, int count = value.Length - start) Now we get two functions for the price of writing one, and better yet, we won't have to document the second one. When I type str.Split, I don't want to see two overloads when one with default parameters would do. I don't need to see two sets of documentation for identical functions. -Jeremy
# Jeremy said on December 3, 2003 10:03 AM:
This is probably a bad place to post this, but since we're talking about features of C#, I'll add it. Declaring variables in C# is a pain. How many times must we write: type variable = new type(some parameters). Seems redundant, and is hard to read. How about this: variable := type(some parameters). Even better, variable := any_expression. Some examples, with C# equivalents: a: = 0; (int a = 0) a:=int[32]; (int []a = new int[32]) a:="hello"; (string a = "hello") a:=MyClass; (MyClass a) a:=MyClass(); (MyClass a = new MyClass()) a:=MyClass(3); (MyClass a = new MyClass(3)) a:=MyClass[n]; (MyClass a = new MyClass[n]) a:=MyClass(3)[n] ... -Jeremy
# clair burke said on December 5, 2003 8:26 PM:
clair burke
New Comments to this post are disabled

Search

Go

This Blog

本博客中文版 (View in Chinese)

These postings are provided "AS IS" with no warranties, and confer no rights.

Syndication

Page view tracker