|
Looking at the arguments on both sides, it looks to me as though conflict resolution is possible. I believe there is a win-win situation:
Make optional parameters a syntactical shortcut for overloading.
ie,
int dosomething(int a, string b, float c=1.2);
should be a shorthand for:
int dosomething(int a, string b, float c);
inline int dosomething(int a, string b) {
dosomething(a, b, 1.2);
}
Then I think all complaints on both sides evaporate.
- convenient syntax
- allows easy changes to an existing framework
- something that looks like a call to 'dosomething(int, string)' actually IS a call to dosomething(int, string), not a call to some secret function with peekaboo parameters.
Is anyone still unhappy with this suggestion?
|
|
|
|
|
I agree. I've always thought it should work this way.
Michael Flanakin
Web Log
|
|
|
|
|
Like some have said, I prefer overloading if the needs calls for it and the language supports it. However, if you're writing in a language (like VB6) that doesn't support overloading, then I prefer the use of optional parameters.
And, while I don't prefer VB6, I'll code in whatever helps me make my house payments. 
Jeremy Falcon
|
|
|
|
|
why use paraaraararararamaters just use global DUH variables DUH! I m a windows guy and i say DURRRRR i pooped myself!:->
|
|
|
|
|
Arguably, it also promotes laziness.
With a language that provides overloading, it's merely syntactic sugar. It goes against object-oriented ideals and is often confused with polymorphism--which it isn't. It's basically a hard-coded value, a define--something frowned-upon by C++ experts.
Anyone who argues against a switch statement in object-oriented programming should also argue against default parameters.
It could be useful for non-integral types; but C++ does not make that distinction, and makes its use potentially dangerous.
An interface (function interface in this conversation) is a contract between the interface and the consumer that must never be broken. In C++ It's easy to see when the contract is broken when you change the type of a parameter (most of the time); but not possible in all circumstances if the default value of a parameter is changed.
Sure, we're all guilty of being lazy and using default parameters, avoiding redesign or avoiding writing another overload. Default parameters should be put on the shelf with GOTO and multiple inheritance because they cause more problems then they solve: decreasing clarity and maintainability.
PeterRitchie.com
|
|
|
|
|
Hello,
This is one of those endless discussions that nobody will ever win. It's just like everything else in life: there is simply no universally best solution, one has to decide on the moment what is best.
Those decisions have to be made in the design stage of the system / library / etc. and you could consider the following:
- What kind of code am I writing: a library, a feature for a system, a major component or just a small one?
- Is it likely that the code is going to be re-used over and over or will it be used in a lot of applications?
- If the code is going to be re-used, is the class going to be derived from and if yes, is this method going to be overridden?
And I'm sure you can think of many more of questions like the above. You should choose a solution based on the answers and what you think is best.
Just MHO
|
|
|
|
|
Very true, but if the language doesn't support them at all then that decision has been taken out of your hands.
Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.
|
|
|
|
|
Ditto! I don't appreciate when a language designer decides for me what language feature is useful and what not in the software I develop. Just give me *everything* and let me make a choice.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
wow so you don't like individuality, no custimization, no options. how about if a method paints red for the background but you want a blue background, are you gonna remake a whole method or are you gonna overload it?? better yet do you use c++ and directx by any chance? how would dx know which window handle to use, hell it would probably cause an irreversible system crash :P
IM PROUD TO BE A GMAIL;
|
|
|
|
|
If you design your methods, classes and libraries like that, I suggest that you follow a workshop or 2!
I design my applications and such as flexible as possible! I hardcode almost nothing. I even put all the strings on my GUI in a string table in a seperate DLL, even if the application is only in one language.
My major language is C++ and I have worked on a DX project with a friend of mine. After the design phase, we thought that we had a sound design, but after getting to know DX we redesigned the whole program, just to be able to create a reusable DX library for follow-ups...
Now I ask you, if you have your method painting the background red and after you decide that blue is also nice to have, you overload the method. Now you start thinking that yellow, purple and green are possible backgrounds you want. Are you going to overload the method another 3 times or do you slam yourself that you didn't design the method to be flexible in the first place?
That is a typical thing why a lot of old school DX programmers write spaghetti code. They use globals where they can and hardcode the as much as they can just to save a CPU cylce or 2. I prefer less optimal code and more flexible and maintainable code because the only bottleneck nowdays is the graphics card...
I hope that this gives you a view about my way of designing and programming.
P.S.
The way I let DX know which window handle to use is to pass the window handle as the FIRST parameter in every method that might need a window handle...
|
|
|
|
|
i know you weren't replying to me... you may have misunderstood me, i don't like to hardcode anything, i was actually making a point against that, maybe you replied to the wrong message
|
|
|
|
|
i know you weren't replying to me... you may have misunderstood me, i don't like to hardcode anything, i was actually making a point against that, maybe you replied to the wrong message sry about the second post
IM PROUD TO BE A GMAIL;
|
|
|
|
|
They are a powerful feature. However in programming, it is best to make the assumption explicit. So I will always call my functions providing the optional parameter as well, even if its value is the same as specified.
|
|
|
|
|
Instead of using optional parameters, try something a little cleaner. Pass an object. The object can have properties representing each of the parameters, and they can even default to a given value.
This has a few advantages, not the least it works in most languages. It also helps to keep method signitures stable, short etc etc...
Just my two cents...
|
|
|
|
|
That could be even worse than optional parameters. For example if you add a property somewhere in the middle of the class, the offset of all the other properties changes. Your old binaries would break just because of that...
|
|
|
|
|
* There is no way for a generic function to find out what the default value is, so they can't generally be used in generic code.
* They are the reason for some silly rules, such as you can't take the address of an STL function (hidden default arguments are legal in an STL implementation).
Overloading is easier to understand, and it results in more optimal code. Default arguments have nothing in their favour, as far as I can tell, except that they were easier to implement. They are an annoying relic of a past era. C++0x should abolish them.
Template default arguments are more useful, but even there I would rather get rid of them and replace them with template typedefs.
|
|
|
|
|
When having to work with COM, optional parameters are great! Otherwise, I see no problem with them, although why not build a method group?
|
|
|
|
|
I avoid optional parameters because all too often, I see people (ab)using optional (and also, out or ref) parameters because they have a class missing on a model.
I see dead pixels
Yes, even I am blogging now!
|
|
|
|
|
|
Mwah, you can reroute the methods internally e.g.
public void DoSomething(String a) {<br />
Console.WriteLine(a);<br />
}<br />
<br />
public void DoSomething(String a,String b) {<br />
DoSomething(a);<br />
Console.WriteLine(b);<br />
}
The reason why I don't like optional parameters is: Why you define them in a method signature when you don't need them?
WM.
What about weapons of mass-construction?
|
|
|
|
|
Cose you can default them.
Eg:
<br />
public void SendOrder( string asset, Side side, double price, double size )<br />
{<br />
SendOrder( asset, side, price, size, null, null )<br />
}<br />
public void SendOrder( string asset, Side side, double price, double size, string clientid, string allocationid )<br />
{<br />
}
Now, you want to call the first one in 99% of the cases.
You need the second method _only_ in one case.
1. Why do you need to define two methods?
2. Why would I make all the calls to the second method and drop null params all the time in?
Wouldn't it be nice if you would have:
public void SendOrder( string asset, Side side, double price, double size, string clientid = null, string allocationid =null ) ?
Look at how dbs are designed. You can always have "nullable" columns for the same reason. You might not need a specific parameter all the time. Why to do the overhead in all your calls to drop some null params just because in 1 case you need them?
Also why write proxy functions and fill code with crap just to reroute one call?
My 2 cents .. and 2 optional params 
|
|
|
|
|
I commonly use default arguments at the start of a project because it saves you some typing and broadens the view on things to come (I'm induced to think twice about assumptions rendred obsolete by parameters 'in the waiting'. But by the time I commit my changes, most default parameters will have been removed, because they enforce an argument order, which tends to be non-intuitive or non-standard and thus makes your lib/class/... harder to use.
Wolfgang Reichl
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
