|
I tend to use them to append a class interface without breaking existing code. Eg.
int MyMethod(int a, int b)
Can be changed to:
int MyMethod(int a, int b, bool additional = false)
Usually I would have useful variables rather than a boolean.
|
|
|
|
|
I'm with Paul too. I use them frequently to enhance some method, but don't wish to re-visit all of the existing code and re-compile.
Chris Meech
I am Canadian. [heard in a local bar]
Gently arching his fishing rod back he moves the tip forward in a gentle arch releasing the line.... kersplunk [Doug Goulden]
Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
|
|
|
|
|
Not surprisingly, if you revisit the C++ language design documents for this feature, this is its exact intent. A class member function requires a new argument, but you don't want to have to rebuld or edit the world, so you add the 'new' argument and set a default value.
|
|
|
|
|
Blake Miller wrote:
Not surprisingly, if you revisit the C++ language design documents for this feature, this is its exact intent. A class member function requires a new argument, but you don't want to have to rebuld or edit the world, so you add the 'new' argument and set a default value.
.Net gives you ObsoleteAttribute : Attribute.
-- Being innovative means not being afraid to get fired.
|
|
|
|
|
Freaky - half the time that I use default params is to do exactly that.
[ Jason De Arte | Toy Maker | 1001010.com ]
|
|
|
|
|
Exactly. I have been working on a new project and I find that quite a few times in the last few weeks I had to add some additional functionality to class methods in libraries that most of my projects use. It is an enormous timesaver to add a default parameter to the method in a way that it would not break the existing functionality but allow the new functionality.
BTW: Even with that said I voted BAD, because if used too frequently/carelessly especially with overloading they can introduce bugs in your application that are difficult to track down.
John
|
|
|
|
|
>>Why you define them in a method signature when you don't need them
1. The clue is in the name "optional"
2. They allow for optional behaviour of a method
3. They accomodate refactoring
4. They accomodate code reuse and enhancements without breaking an existing code base
Phil Harding
|
|
|
|
|
Phil Harding wrote:
2. They allow for optional behaviour of a method
3. They accomodate refactoring
4. They accomodate code reuse and enhancements without breaking an existing code base
So does simple method overloading. None of these is really a valid argument in the whole optionalParameter vs. overloadedMethod debate, which seems to be where this discussion is headed.
Personally, I prefer overloading. With overloading, there's never any doubt as to whether the calling method didn't specify the parameter, or just happened to specify the "default" value for the parameter. Sometimes the distinction matters.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
|
Another problem with optional parameters has to do with changing the default value.
If I compile against a method with an optional parameter, and I leave out the optional parameter, my code is actually compiled with the current default value of the optional parameter explicitly built into my binary. If a new version of the library I'm using comes out, and this new version has a different default value for the optional parameter, my code will continue to send the old default value unless I recompile it against the new version of the library.
However, if the library is done with overloaded methods instead of optional parameters, then whatever default value the library elects to use when I leave off a parameter, that default value is internal to that library, and not compiled into my client code the way it is with optional parameters. So new versions of that library can come out with different default values, and it won't break my code or force me to recompile it.
Joel
|
|
|
|
|
Grimolfr wrote:
None of these is really a valid argument in the whole optionalParameter vs. overloadedMethod debate, which seems to be where this discussion is headed
And the original question is not "which is better?". It is: "do you want to have optional parameters or not?". I still can't see why not? Give more choice to programmers.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Give more choice to programmers
I agree. Just because a language adds optional parameters, does not mean that it must eliminate overloading. Optional parameters are a feature.
As for generics, why not designate a "default_value" keyword that would give the default value for a type? For example, if your class has a generic type, T, then you could define a method as follows:
void mymethod( int a = 0, string b = "", T c = default_value ) {...}
-Steve
|
|
|
|
|
I personal perfer overloading for one reason only.
1) It requires the user of the method to always pass in the required values to make the method work properly.
By this I mean that often when you Change one parameter from the default you are required (logically) to often change another parameter.
With overloading this behaviour is enforce by the compiler, ie.e if I want to change that parameter I have to change the other. Where as optional parameters require me to read the doco to find out any inter-relationships between the parameters.
Then again, the majority of time I have seen overloading jsut creating more code...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
