C# Feature Focus: Optional and Named Parameters, COM Interoperability
Due to overwhelming customer demand, Anders has "relented" and allowed Optional and Named Parameters in C#. Just like VB, optional parameters are supported by including a default value. And like in VB, required parameters must all appear before any optional parameter.
Named parameters are also supported fully. This allows developers to specify the parameters in any order they see fit. This works with normal as well as optional parameters, one would expect to only see it when dealing with the latter.
When resolving expressions used as arguments, the order is strictly determined by the code making the call irregardless of the order in the function's signature. And though not recommended, this means expressions with side effects can be more or less safely used as arguments.
COM libraries have a bad habit of returning values as type Object. To address this, C# 4 will automatically promote any object returned by COM to the "dynamic" type. As we mentioned in the previous article, this allows late-bound calls on the object just as if the developer had manually written all the necessary reflection code.
The "ref" modifier will no longer be needed for COM calls unless by reference semantics are actually needed.
In the end this means code that used to look like this:
//C# 3 var a = (IFoo) obj.Foo(ref missing, ref missing, ref missing, ref missing, ref missing, 5, ref missing, ref missing, ref missing); var b = (IBar)a.Bar(); var c = b.Value; //C# 4 dynamic obj = //some COM or DLR object var c = obj.Foo(clientId := 5).Bar().Value
There was also a rumor about parameterized properties. We will post an update once we have more information on it.
Overwhelming demands, but from who..
Thus, I can't help but feel that these "demands" come from people who shouldn't even be using C# in the first place. I used to ask for optional/named parameters a lot, but I also have a VB6 background on top of having worked a lot in dynamic environment. C# was more the "purist" language. If C# goes the "kitchen sink" way... which language will be there for purists (and considering the rise in popularity of C#, and the ups and down of Java, it seems like there definately is a market for these "pure" languages).
Right now all I can see, is C# with a bunch of custom FXCop rules to weed out potential messes.
Re: Overwhelming demands, but from who..
I come from an C & IDL background as two different languages for two different purposes. I now see C# growing out into a massive mess (the kitchen sink you're talking about) and that's not a good thing.
Especially with the possibilities to easily interconnect to different .NET assemblies in different languages, I don't understand the need to stick everything in one basket instead of just writing different, smaller, more specialized languages for .NET.
In this fashion, each team/company will only be allowing a subset of C# which will only confuse new developers/teammembers who were used to using the rest.
I guess I'll just watch it and continue pondering.
Re: Overwhelming demands, but from who..
Java anyone? It used to be the lean and mean "purist" language. It had very few, very consistant constructs. It -was- missing some (generics), and they were added... but then they felt the need to add everything. What happened? Exactly what you mentionned: people turned to arguably better, specialized languages (Groovy, Scala, etc). Java isn't going away because it IS still good, and it is the cobol of our time (so much done in it), but people aren't happy about it. Thats half the reason .NET was successful in the first place.
No one want a kitchen sink language... C++ was enough. Same thing will happen with C#... someone will build a new language, similar to C#'s root (plus the actually useful extensions, like lambdas and LINQ), and C# will be legacy "so-much-code-already-written-we-cant-throw-it-away" stuff.
Does no one learn from history?
John Altidor, Yannis Smaragdakis Mar 30, 2015