New in C#4

Nick Sabalausky a at a.a
Wed Oct 29 13:59:27 PDT 2008


"Denis Koroskin" <2korden at gmail.com> wrote in message 
news:op.ujsxznwqo7cclz at proton.creatstudio.intranet...
> On Wed, 29 Oct 2008 17:37:25 +0300, bearophile <bearophileHUGS at lycos.com> 
> wrote:
>
>> Thanks to Reddit I have found a nice short document that lists some of 
>> the differences of C#4:
>> https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv
>>
>> They have added a dynamic invocation, useful if you want to implement a 
>> dynamic language (like IronPython, IronRuby, etc) on top of the dotnet. 
>> Object-C shows this is doable in a very C-like language, and the Boo 
>> language shows that in a statically typed language it can be useful to 
>> use a Duck type once in a while to reduce the "static type pressure". 
>> More info on this last concept in the Boo site.
>>
>> Something that I like a lot is the named arguments, that I hope to see 
>> in D and Delight someday. They are used often in Python, and they help 
>> increase the readability of the code, sometimes even reducing mistakes.
>> They have used colons:
>> foo(x: 1, z: 3)
>> While Python uses equal signs:
>> foo(x=1, z=3)
>> I think they are about equally readable.
>> (I think there's a problem with named arguments, that you can solve in 
>> some ways, for example with an extra hidden bitfield argument that 
>> encodes what arguments are given and what not).
>>
>> Bye,
>> bearophile
>
> I'm waiting for named arguments, too! They make could more readable and 
> self-documenting:
> graphicsDevice->updateSettings(true, true, false, true); // wtf??
>
> Compare to the following:
> graphicsDevice->updateSettings(fullScreen: true, verticalSync: true, 
> enableBloom: false, fullScreenAA: true);
>

I was just going to bring up the "series of bool params" issue. I very 
frequently find myself going out of my way to create trivial enums just to 
avoid using bool parameters.

Similar to named parameters, as much as I normally dislike VB, I've long 
been jealous of its "optional params can be in the middle" capability.

For instance:
void foo(int a, char[] b, int c=0, char[] d="", int e, char[] f, bool 
g=false) {/*...*/}
foo(17, "blah", , , 8.4, "stuff"); // <- Wow!!

That makes it *enormously* easier to design APIs with optional parameters. 
No more mucking around with potentially-conflicting function overloads just 
to work around the "optional params must be last" requirement. No more 
conflict between the desire to organize params in a conceptually-logical 
order and the need to, again, put the optional params at the end.

Plus, it seems like it would be fairly simple to implement. It's always 
seemed like a fairly obvious feature to me.





More information about the Digitalmars-d mailing list