As a C# MVP, I am obligated to tell you that Edit & Continue is in C# now in this build regardless of my feelings...When I started reading about the new functionality, I was wondering ( and about to blog ) my concerns that C# E&C would suffer the same limitations that make Java "Hot Swap" functionality such a pain^h^h^h^hjoy to use, when I spotted Sean Malloy's comments:
Check out the features that didn't make it:This pretty much matches the problems that plague Java's Hot Swap functionality, you can't introduce updated classes that break the contract of the existing class imposed by the static nature of the language. On some level I can understand this, you don't want to introduce something that would start breaking other classes, Smalltalk systems would just start throwing out #doesNotUnderstand in this instance, and the hacker can just "implement and continue", not just edit and continue. Java already throws these sorts of errors when you've compiled against one version of a class, but run against another (with missing methods), I don't see what the problem of doing this during E&C is either. On the other hand, the E&C feature could be implemented to impose contract checks, if you add a method, or change parameters as part of a refactoring, as part of injecting the new class into the running VM, also inject new copies of the dependent classes - this way the IDE "knows" all classes are valid before injecting them; although that being said - it should be the VM that handles the injecting, not the IDE. This is one area that Java has up on C# I believe, any application that supports the JPDA debugging extensions can replace classes ( within these horrible limitations thou ). E&C sure makes life easier, but it also comes with its own pain and frustrations.
- Changing the name of a class
- Adding or removing method parameters
- Adding public fields to a class
- Adding or removing methods
Hey, who is this Sean Mallow fellow? ;)
Sean Malloy
Ewps - my bad, thought I'd fixed that typo. Done now thou :)