This post originated from an RSS feed registered with .NET Buzz
by Eric Gunnerson.
Original Post: Enforcing patterns at the compiler level
Feed Title: Eric Gunnerson's C# Compendium
Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx
Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles
.. your thoughts on enforcing patterns at the compiler level.
As an example: - excluding the public scope from field declarations, making them private by default and only private. - declaring a field as public appears as a compiler warning (level x)
or an abstract example - putting accessors (constructor like) on the object level, so that we can code against someone setting an instance to another as in myobj = yourobj (yourobj fires a get, myobj fires a set)
We haven't talked about this at length in the design meetings I've been at, but there is a big gap in my attendence.
Given that we already have an extendible tool like FXCop available, I don't think it makes sense for each compiler to do work that would duplicate the FXCop features. I'm fairly sure that both of your first examples can be done in FXCop now.
The abstract one could either be done by post-compile IL analysis, or it could be done by a compiler. Doing so in the compiler would be difficult to do in an general way, and our compiler architecture doesn't really lend itself to that sort of things.
Philosophically, it would be nice to have some way to leverage the knowledge that the compiler has about the code, but we don't currently have any plans in that area.
Jonathan, can you comment on why you want to be able to detect reference assignments? I'd like to understand the scenario better.
Previous Topic
