Inside C# 4.0: dynamic typing, optional parameters, covariance and contravariance | Going Deep

gallo

I'm wondering what influence the optional and named parameters will have on interfaces and inheritance in general. Will a method parameter have to have the same name in an implementation as in the interface? This would help for code quality and maintainability. If not, will the compiler keep track of how a parameter gets renamed in the inheritance hierarchy or do all signatures get treated individually? Can a non optional parameter be made optional in an inherited method? What about the other way round?

One more question: when will C# get XML literals like Visual Basic? I've been waintig for this since Comega...

Wolfgang

Tengiz

Isn't late binding evil? Don't we want compile time errors and not want runtime errors?
I guess, if you have to interact with something non-native, this is pretty cool.

Never mind, I think i got it Smiley

aL_
Rx ftw

i think the people who's critical of the dynamic keyword really should watch anders session on pdc.. (future of c#)

first of all, compared to fuby for example c# has relativly few keywords (including keyword overloads) imo

the dynamic keyword is not exactly hard to learn, its basically just a special type, and it enables so soooo much.

i dont think one should regard the dynamic keyword as a feature for c# per se, but for interop with other things that arent c#. there will always be need to talk to com, talk to js (in silverlight in perticular) and increasingly, talk to things written in dynamic languages. Thats what the dynamic is for..
no one is suggesting that all c# code should be re written to use the dynamic keyword.. its just an option to enable things that used to be really hard or even impossible

as anders said in his talk, convergence is the key.

watch the talk.. its pretty awsome Smiley

great work c# team : ) cant wait to get my hands on this stuff Smiley

aL_
Rx ftw

by the way, the true awsomeness of the dynamic keyword and the dlr is imo that you can create your own resolve mechanism.. for example in anders sessions he creates a dictionary that, if its cast to a dynamic, gets the keys from method calls:
dic.key = value

pretty heavy stuff..

its its all just opt., you dont have to use any of the dynamix stuff if you dont want to Smiley

Dark_Halmut

Ive worked a good amount between C# and COM. Optional parameters are nice, but i've found ways to work without them. I think allowing reordering of parameters is only asking for trouble. Especially in the talk the first thing talked about with this feature is how developers can screw themselves. I think it weakens the language to let things blow up at runtime rather than compile time.

Great that these things are possible but I don't plan on using them.

Tanveer Badar

According to Sam Ng, around 16:00, DLR binds arguments according to their runtime type. However, function overload resolution is based on static types of argument in all languages known to me. My knowledge could be lacking in this case.

saidinarts
You know sometimes I amaze even myself. - Han Solo

Perhaps I'm missing something here - and somebody can point this out to me. In regards to default parameters and named parameters, is this done at the compile time or run time? If I am calling a external class as such Foo(x:1,y:1), and they change there class from Foo(x, y) to Foo(z,y), would I still work because it still has the same type of footprint because it was done at compile time? I think it would, from what I got out of it. However, if I recompiled mine, I should get an error as x no longer exists, and I should change it to z. Now how about default params? If I call Bar(x:1) to a defined method of Bar(x, y=3), then I would make the call with a value of 3. But if the method is changed to Bar(x, y=7), do I make the call now with a 7 or a 3 - is it based on compile time or runtime? I would hope it is runtime, as you grab the current value based on the current metadata of the class - but I don't know.

aL_
Rx ftw

ive got a question about the method caching in the dlr..
what if the arguments of a method is of type dynamic? lets say ive got a ruby int and a ruby string and i pass that into a ruby method M, all from c# (by calling libraries written in ruby for instance)

how would the dlr cacher handle that? both the arguments whould be dynamic but actually contain diffrent types..
im pretty sure the dlr handles it but it would be fun to hear more about that Smiley

awsome work as always charles Smiley

TimothyP

Tell you one thing, the dynamic keyword is going to reduce the amount of code required
to use reflection and such. I'm all for it.