Versioning, Virtual, and Override
Summary:
Anders Hejlsberg, the lead C# architect, talks with Bruce Eckel and Bill Venners about why C# instance methods are non-virtual by default and why programmers must explicitly indicate an override.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: November 15, 2004 0:53 PM by
Shital
|
|
|
And, yes, I agree with Darren. In my words: I think it's arrogant to imagine that I can predict every future use of my code.
The last days I have struggled with the User Interface Application Block. Every attempt to make it do what I want has been effectively been stopped by a sealed class, an internal class or a static method. And the object creation happens deep down below the sea level. It's impossible to inject a specialized class into that mess. Not all classes can be correctly created from config information alone.
|
|
|
|
Here's my take: http://www.shitalshah.com/blog/default.aspxOne major issue that Anders mentioned was performance issue. I think its easy to mitigate the performance issue by making hot methods non-virtual explicitly. Also this is applicable to only public methods. Its far more difficult to analyse every side effect of overriding every method by someone someway. The problem is that people does want to let their methods overridable but they don't have time to analyse effects and make promise that overriding would work normally. So the solution is compiler warning rather then making it fianl-by-default.
|
|