This post originated from an RSS feed registered with .NET Buzz
by Eric Gunnerson.
Original Post: Still more on virtual by default...
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
In a bid to keep my blog hits high, I've decided to revisit this again.
The comments (I read all comments, though I don't respond to all of them) have been fairly split.
There has one group who agrees with me, and another group that is opposed to my perspective. I'd like to address those who disagree with me, as there are a few points I didn't cover last time.
I do want to state up front that this is an area in which there is room for honest disagreement.
I think the point htat I didn't make very well earlier was that one of the reasons we're somewhat - okay, perhaps “paranoid“ is too strong of a term, but it has the right “feel“ - is that if we had a virtual method on a class but didn't support it, there's a likelihood that it will break in the future (the discussion of how likely that is is an interesting side discussion. Some may argue that it is likely, others may argue that it's not likely at all. ).
If that break happens, I don't expect the customer response to be, “Oh, it broke, so I guess I shouldn't do that“. I expect it to be more along the lines of “Why didn't Microsoft build this thing correctly in the first place?“, which is why we work very hard to avoid that situation.
There's one other point I'd like to raise. When you look at a class and there's a method that isn't virtual, you rarely have any idea why it isn't virtual. It coul be that the designer just didn't want to support that as a virtual. But it could also be that making it virtual would raise a security issue, or cause your cat's fur to fall out.
Previous Topic
