This post originated from an RSS feed registered with .NET Buzz by Paul Vick. Original Post: Refactoring and drafting, revisisted Feed Title: Panopticon Central Feed URL: /error.aspx?aspxerrorpath=/rss.aspx Feed Description: a blog on Visual Basic, .NET and other stuff Latest .NET Buzz Posts Latest .NET Buzz Posts by Paul Vick Latest Posts From Panopticon Central

In response to my entry on refactoring in VB 2005, some have asked why VB couldn't take advantage of C#'s work on refactoring the same way that C# took advantage of VB's work on Edit and Continue. I anticipated this would come up, and the answer is that some features are subject to drafting at the current time and some aren't.

Edit and Continue is a feature that spans the compiler, the debugger and the CLR. As such, work done in the latter two areas can be applied across all the languages that want to take advantage of Edit and Continue. Refactoring, on the other hand, is a feature that is currently implemented entirely within the compiler. Thus, there's no opportunity for taking advantage of the work that other teams have done on the feature.

Now, one could certainly imagine a world where it might be possible to share the work on refactoring across the languages, but we're just not there yet. Refactoring requires an intimate understanding of the structure and meaning of the code that's being modified, which is why it's currently implemented as a part of each language's IDE component. If there was an abstraction layer, however, that could abstract away the different syntax and semantics of the languages to such a degree that one could manipulate C# and VB code in a language-independent way that preserved semantics, then common refactorings would be possible. At the moment, though, neither VB nor C# is architected in this way.

Given some of my experiences with the CodeDOM and WinForms designer trying to do a much simpler form of this, I'm not entirely sanguine that such an abstraction layer is possible. Perhaps some of the third-party refactoring tools will prove me wrong on this. It's something that we talk about and will think about as we move past 2005, but for now each language is on it's own as far as refactorings...