This post originated from an RSS feed registered with .NET Buzz by Eric Gunnerson. Original Post: Customer-Focused Design 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 Latest .NET Buzz Posts Latest .NET Buzz Posts by Eric Gunnerson Latest Posts From Eric Gunnerson's C# Compendium

In the C# Language design team, our philosophy is one that I sometimes refer to as “Customer-Focused Design”. Our goal is to build a language that makes our customers more successful.

We've done a fairly good job of making the right design decisions, but there have been times when we've had do change something due to customer feedback. Since the first release of C#, customers have asked for different accessibility on get and set accessors, and though we feel (or I do, at least) that that does make the model somewhat less crisp, enough people have asked for it that we decided to add it in Whidbey.

Sometimes responding to customer feedback is harder...

As you've probably figured out, one of the things that PMs do is spend a lot of time interacting with customers. Some of it comes through web forums, some of it comes through my blog, and some of it comes through email and even through less-technologically-advanced means.

Since February 1st, I've been getting a ton of negative feedback about the C# language, and two weeks ago we were notified that the FCLC was shopping a proposed rule, so we've been talking about the issue in our design meetings. It's been a very contentious discussion, but we have reached an agreement, and since this is going to show up in the next Whidbey partner drop, I've decided to talk about it here.

I thought it might be more interesting for you if I just copied from the design notes.

*****

35.1 Keyword Changes for Whidbey

We recently discussed (see 30.6) some possible changes to a few of the keywords. Eric has spent some time with legal discussing whether we really need to do this, and they feel that we have no choice, especially given the commission's new “hands-on“ approach.

The design team as a whole is concerned about the impact this change will have on customer code, but we are agreed that it is better to get it into Beta1 to give people more time to modify their code.

We've agreed on the following new names for keywords.

We believe that these changes are sufficient for those who were offended by our current keyword set. Eric will work with legal to make sure this is enough to satisfy the FCLC.

We elected not to include 'override' or 'lock' in this list, but we might have to revisit that decision later.