Please follow up with more from DevDays 2010. Also, the video and audio quality are superb! All encodings of presentations should be this good.

posted by Corrector2

class MyClass 
{ 
MyClass() : this(string.Empty, null) 
{ 
} 
 
MyClass(string someString) : this(someString, null) 
{ 
} 
 
MyClass(string someString, Object someObject) 
{ 
// Do something with someString and someObject
 } 
} 

than

class MyClass { MyClass(string someString = string.Empty, Object someObject = null) { // Do something with someString and someObject } } 

which is far less ceremony and far more essence than the former.

Edit: well, the code layout is messed up so my point is lost. Thanks again, Channel 9 forum software.

posted by Bas

posted by Matthijs

posted by spivonious

posted by felix9

he pointed out a caveat that when optional parameters are used, the name of the argument suddenly start to matter. if you make a seemingly innocent change to a argument name in a library, all callers that use that argument by name will break

also, bart wrote that, at least in the c# implementation, the values for optional parameters are "burned into the call site" that is, a method like this void Add(string firstName, string lastname = "") could be called like this:  Add("aL"), however what the compiler will actually emit is Add("aL", "")

this means that even if the library writer where to change the default value for a optional parameter, the callers wouldnt pick up that new vaalue unless they recompiled their code.

maybe he thinks it promotes "bad" design, that is having to many arguments.. but surely the users of such libraries *cough*office*cough* shouldnt have to suffer for that

posted by aL_

posted by felix9

posted by venkatbaggu

posted by ShinNoNoir

If that's true, then that's a really poor design decision from the compiler team. Optional parameter default values should be set in the method, not in the caller.

posted by spivonious

http://channel9.msdn.com/posts/adebruyn/TechDays-2010-Developer-Keynote-by-Anders-Hejlsberg/

posted by N2Cheval

It's also the case for constants in C#, which I think a lot of developers don't realize - that the constant value is burned in, so changing a constant in a referenced assembly won't change the value in dependent assemblys unless they themselves are also recompiled.

I'm sure that they have good reasoning for doing the same for optional parameters in C#, even if it may have adverse affects in some scenarios.

posted by pspidey512

Were there any lectures on F# at this DevDays conference?

posted by Jon Harrop

posted by vesuvius

posted by sreejithssnair

posted by thabet084

However, I wish he talked more about the debugging and specific run time errors that can occur.

The problem with dynamic, as far as I can tell, is that since you could give a dynamic variable anything you want, you won't know if it will work until you run the application at run time; but even then, you won't even know where the error will be in the code!

I can see debugging dynamic variables to be a big futuristic problem (part of the reason why many people don't like javascript), especially if you're asking the program to do what you want it to do, and it's not complying properly to your request. It would be quite difficult to track down problems if they occur. The only thing you'd be left to run on is how well you can design your code to narrow down where an error could result.

If Mr.Hejlsberg dedicated sometime to show possible runtime errors, and if there is some kind of message handling that will explain viable reasons as to why something is not working, I'd program using dynamic variables with higher confidence. But as far as now, I feel a little effy on making the leap and spending my time asking others why something isn't working.

posted by sksallaj

However, I wish he talked more about the debugging and specific run time errors that can occur.

The problem with dynamic, as far as I can tell, is that since you could give a dynamic variable anything you want, you won't know if it will work until you run the application at run time; but even then, you won't even know where the error will be in the code!

I can see debugging dynamic variables to be a big futuristic problem (part of the reason why many people don't like javascript), especially if you're asking the program to do what you want it to do, and it's not complying properly to your request. It would be quite difficult to track down problems if they occur. The only thing you'd be left to run on is how well you can design your code to narrow down where an error could result.

If Mr.Hejlsberg dedicated sometime to show possible runtime errors, and if there is some kind of message handling that will explain viable reasons as to why something is not showing, I'd program using dynamics with higher confidence. But as far as now, I feel a little effy on making the leap and spending my time asking others why something isn't working.

posted by sksallaj

posted by jarenduan

posted by cbae

Matt, thanks for putting these up; the quality is fantastic!  I can't thank you enough!

posted by codecop