tag:blogger.com,1999:blog-3573606178901893990.post9040359307008873221..comments2024-01-28T01:30:51.917-08:00Comments on The Monkey's Grinder: Now Is The Winter of Our Optional and Named ParametersUnknownnoreply@blogger.comBlogger17125tag:blogger.com,1999:blog-3573606178901893990.post-25981434725845350262011-10-29T08:50:31.654-07:002011-10-29T08:50:31.654-07:00This won't succeed in reality, that is exactly...This won't succeed in reality, that is exactly what I think.sex shop markethttp://www.gsqx.com.cn/you-wil-be-more-attractive-at-the-shop/noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-74023930782908623732009-02-23T22:38:00.000-08:002009-02-23T22:38:00.000-08:00Changing the default value does not break the cont...Changing the default value does not break the contract. It is exactly like changing the default value passed from an overload with fewer parameters to one with more.<BR/><BR/>If you take issue with the larger problems of having optional/named parameters in a public API, I would probably agree with you. I'm not really a fan of the language feature. But it is coming to C# 4 regardless.Scotthttps://www.blogger.com/profile/13066415518426794033noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-70255052098582984172009-02-23T20:18:00.000-08:002009-02-23T20:18:00.000-08:00Say that all you want, that's *not* how it will ge...Say that all you want, that's *not* how it will get used :)<BR/><BR/>Consider that a company will spend vast sums just to certify their app, which may just happen to use default values regardless of how you or they interpret it. If you decide to break your contract by changing the default value, you just wasted their time and money. I wouldn't want to take a dependency on that.<BR/><BR/>Default values represent a contract in that regard, which shouldn't be broken. Recompiling is a trivial means of protecting against such breaches.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-91103624588308010262009-02-23T19:30:00.000-08:002009-02-23T19:30:00.000-08:00@Keith: Default values are the purview of the part...@Keith: Default values are the purview of the party writing the function. If a consumer uses a default value, they want to use "the default value," not "the string literal 'STELAAAA!' which, at the time of compilation, was the default value." Consider method overloads. If I provide an overload with fewer parameters which calls through to an overload with more parameters, passing "default" values, then those values are under my full control. I can change the default values and all release a new version of my assembly and all code which consumes it will use the new default values w/o recompilation. This is just how the concept of default values works. If the consumer code actually wants to use a particular literal value, they can specify it. If they want to use whatever the "default" value is for a parameter, then that value must be under the control of whoever wrote the function - they are the one who knows what the "default" value should be.Scotthttps://www.blogger.com/profile/13066415518426794033noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-75116736805831669442009-02-23T11:50:00.000-08:002009-02-23T11:50:00.000-08:00You *should* be required to recompile to take adva...You *should* be required to recompile to take advantage of a new default value. Though, admittedly, you probably shouldn't be changing default values to begin with.<BR/><BR/>The problem is that if you change the default value in the way you propose, you've have effectively rewritten everyone else's code. What if they specifically *wanted* the value that was the default? What if they *required* that value?<BR/><BR/>Default values shouldn't be published lightly. They shouldn't be changed, certainly. They definitely aren't (nor should be) interpreted as a situation where the dev doesn't care about the value.<BR/><BR/><BR/>@Kriz, etc: Consider trying to use C# with COM and the Office APIs in particular. The alternative is precisely what you suggest, but goes into the dozens of paramters (only very slight exaggeration, if at all).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-65801559429852651832009-02-23T02:05:00.000-08:002009-02-23T02:05:00.000-08:00There is bigger problem with named arguments.Simpl...There is bigger problem with named arguments.<BR/><BR/>Simple argument renaming will break API compatibility. Also simple interface contracts are now not enough, implementing an interface using different parameter names can break contract from C# perspective and the list of issues can obviously go on and on.Marek Safarhttps://www.blogger.com/profile/01681406948827313648noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-76817398950667567292009-02-22T17:23:00.000-08:002009-02-22T17:23:00.000-08:00There is no reason you couldn't have optional and ...There is no reason you couldn't have optional and named parameter support in the dynamic member provider interface as well. I don't see how this approach has any effect on the use of the dynamic keyword.Scotthttps://www.blogger.com/profile/13066415518426794033noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-50389620780411480482009-02-22T11:02:00.000-08:002009-02-22T11:02:00.000-08:00Together with the new C# 4.0 "dynamic" keyword/lat...Together with the new C# 4.0 "dynamic" keyword/late binding, optional parameters as designed by MS are very useful for consuming COM objects.<BR/><BR/>Your approach won't be COM compatible.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-38162649665810553572009-02-22T09:39:00.000-08:002009-02-22T09:39:00.000-08:00Passing a structure is not inany way faster/smalle...Passing a structure is not in<BR/>any way faster/smaller than<BR/>passing a bunch of parameters.vargazhttps://www.blogger.com/profile/05287898814224544981noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-75768417441385899352009-02-22T09:24:00.000-08:002009-02-22T09:24:00.000-08:00VB does use callsite injection for optional parame...VB does use callsite injection for optional parameters, but you can still call VB methods w/ optional parameters using C# today - you just need to fill in all of the arguments yourself.Scotthttps://www.blogger.com/profile/13066415518426794033noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-72266774116324395122009-02-22T08:55:00.000-08:002009-02-22T08:55:00.000-08:00One of the reasons they said they were adding this...One of the reasons they said they were adding this at PDC was they want C# and VB.Net to have feature parity. This is something that VB.Net has had I think since the beginning.<BR/><BR/>This causes a problem if you have a VB.Net method with optional parameters that you try to call from C#.<BR/><BR/>I wonder if it is implemented this way in VB.Net and so the C# implementation has to be the same?Jonathan Pobsthttps://www.blogger.com/profile/18092370330717169761noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-72654597722599496962009-02-22T04:24:00.000-08:002009-02-22T04:24:00.000-08:00@Kriz: Not to mention that overloading is in fact ...@Kriz: Not to mention that overloading is in fact a language feature that doesn't keep a clear semantic some of the time when generics are involved.<BR/><BR/>Figuring out which method overload would be called for a generic static method with parameter covariance, polymoprhic parameter type and a generic containing class...<BR/><BR/>You don't really want to be in that space unless you really wanted to C++ instead :)Amberhttps://www.blogger.com/profile/02588145544781882509noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-47714761086107402972009-02-22T04:15:00.000-08:002009-02-22T04:15:00.000-08:00@Kriz: I'm right there with you on being a little ...@Kriz: I'm right there with you on being a little skeptical of optional/named parameters. In fact, Rico Mariani makes the same proposal you do in Framework Design Guidelines about using default values as a way of auto-generating overloads.<BR/><BR/>The problem is, how do you do the overload which just takes humdinger, and the one which just takes wuchacallit. Both are strings, so there is no way to have overloads for each. Also, when you get into the realm of <I>a lot</I> of parameters (which is where optional parameters are most useful) the overloads are tricky or impossible to work out.<BR/><BR/>As far as I can tell, optional and named parameters are a "listening to our customers" feature. Everybody wants then, apparently. I'm really of the opinion that you shouldn't need them in the language: either do overloads, or a *Settings type. But since the masses are clamoring for the feature (whether as a result of the Office APIs or not - don't get me started), it <I>is</I> going to be in C# 4. I'm just offering a better alternative to callsite injection.Scotthttps://www.blogger.com/profile/13066415518426794033noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-82811748363253598082009-02-22T03:11:00.000-08:002009-02-22T03:11:00.000-08:00Why not simply do:public void Foo ( int doodad, st...Why not simply do:<BR/><BR/>public void Foo ( int doodad, string humdinger, string wuchacallit )<BR/>{<BR/> // Do stuff here<BR/>}<BR/><BR/>public void Foo ( int doodad, string humdinger )<BR/>{<BR/> Foo( doodad, humdinger, "STELLAAAA!" );<BR/>}<BR/><BR/>public void Foo ( int doodad )<BR/>{<BR/> Foo( doodad, String.Empty, "STELLAAAA!" );<BR/>}<BR/><BR/>public void Foo ()<BR/>{<BR/> Foo( 1, String.Empty, "STELLAAAA!" );<BR/>}<BR/><BR/>And as a consumer you would simply choose the proper method?<BR/><BR/>Why do we need optional and default parameters at all?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-24186762496335179032009-02-22T03:07:00.000-08:002009-02-22T03:07:00.000-08:00You may well be able to get part of the way you wa...You may well be able to get part of the way you want to with PostSharp.James Websterhttps://www.blogger.com/profile/02970900030884737399noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-12904672289377081632009-02-22T02:31:00.000-08:002009-02-22T02:31:00.000-08:00Polymorphism is a bit tricky. I am using a struct ...Polymorphism is a bit tricky. I am using a struct for the generated type so that it cannot be null (and nothing is allocated on the heap). This means you can't have inheritance from a *Settings type. Another option would be: define an interface type for use in the (generated) virtual method sig. If a derived class wants to provide its own defaults, it can have its own nested settings type which implements that interface. The compiler selects the appropriate value type. If you really wanted to make sure that nobody could ever use a settings type designed for something else in the inheritance chain, then the virtual method (with the interface parameter) could be protected and a public method which takes the exact value type could call through to the protected method.<BR/><BR/>All of this extra jazz with interfaces is only necessary if the method is virtual, obviously.Scotthttps://www.blogger.com/profile/13066415518426794033noreply@blogger.comtag:blogger.com,1999:blog-3573606178901893990.post-73877655936401718312009-02-22T02:09:00.000-08:002009-02-22T02:09:00.000-08:00Fully agreed hereNot to mention the tension betwee...Fully agreed here<BR/><BR/>Not to mention the tension between default arguments and polymorphism (a base class can define a function with a default argument value, whereas a derived a class can override that function, optionally using a different default. It quickly becomes nearly impossible to tell which default value gets used when calling the polymorphic method).<BR/><BR/>Note that this issue stems from my experience with C++, so it could be that C# (.NET) actually enforces consistency across class hierarchies?Amberhttps://www.blogger.com/profile/02588145544781882509noreply@blogger.com