Mark Derricutt's Disturbing Thoughts

My Top Tags

                                       

My Jaiku

Chrome Division – Doomsday Rider

Thursday, 21 August 2008 5:43 A GMT+12

1 Session per VM: Another Scaling Alternative

Wednesday, 20 August 2008 9:47 P GMT+12

The BGGA myth - Functional Java | Google Groups

Wednesday, 20 August 2008 7:33 A GMT+12

Spock's Beard – On A Perfect Day (live)

Wednesday, 20 August 2008 5:57 A GMT+12

Ola Bini: JtestR 0.3.1 Released

Tuesday, 19 August 2008 10:00 P GMT+12

Enslaved – Violet Dawning

Tuesday, 19 August 2008 6:14 A GMT+12

Distributed Messaging with Jetlang and Terracotta

Monday, 18 August 2008 10:17 P GMT+12

The Music of 2008 - week 33

Monday, 18 August 2008 8:57 A GMT+12

There Can Be Only One

Monday, 18 August 2008 8:10 A GMT+12

Search Box

 

Re: Unit tests, Refactoring not Edit and Continue

posted Wednesday, 20 October 2004
As with everyone in the blogging world I noticed all the announcements over the new "Edit & Continue" functionality in C#, Sam Gentile's says:
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:
  • Changing the name of a class
  • Adding or removing method parameters
  • Adding public fields to a class
  • Adding or removing methods

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.

links: digg this    del.icio.us    technorati    reddit




1. a reader left...
Wednesday, 20 October 2004 4:34 pm

Hey, who is this Sean Mallow fellow? ;)

Sean Malloy


2. Mark Derricutt left...
Wednesday, 20 October 2004 4:38 pm

Ewps - my bad, thought I'd fixed that typo. Done now thou :)