Thanks for the info. I knew that they must have had a reason, I just didn't know what it was.
Ian, thanks for the link to Michael Feather's article. I haven't read it yet, but he usually has good things to say. ______________________________ - David Lanouette - [EMAIL PROTECTED] "Excellence, then, is not an act, but a habit" - Aristotle > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of > Fabian Schmied > Sent: Saturday, July 08, 2006 3:44 AM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Virtual methods in .NET - was > Implementing an Interface - C# vs. VB.NET > > [...] > > > If you're overriding a method, you need the other > documentation - the > > one that is rarely provided, or if provided is incomplete: > what other > > methods in the ancestor class will call it - and you need > to make sure > > you don't call them, to avoid an accidental infinite loop. > You need to > > know what the state of the class will be - fully initialized, what > > invariants hold. You need to know what other methods are > safe to call > > and when. > > [...] > > > Unless you missed the whole start of my email - i.e. the > bit where I > > point out that it's not for performance reasons "only", or even > > primarily. > > Following up on this, here's what Anders Hejlsberg has to say > about it [1]: > > <quote> > There are several reasons. One is performance. We can observe > that as people write code in Java, they forget to mark their > methods final. > Therefore, those methods are virtual. Because they're > virtual, they don't perform as well. There's just performance > overhead associated with being a virtual method. That's one issue. > > A more important issue is versioning. There are two schools > of thought about virtual methods. The academic school of > thought says, "Everything should be virtual, because I might > want to override it someday." The pragmatic school of > thought, which comes from building real applications that run > in the real world, says, "We've got to be real careful about > what we make virtual." > > When we make something virtual in a platform, we're making an > awful lot of promises about how it evolves in the future. For > a non-virtual method, we promise that when you call this > method, x and y will happen. When we publish a virtual method > in an API, we not only promise that when you call this > method, x and y will happen. We also promise that when you > override this method, we will call it in this particular > sequence with regard to these other ones and the state will > be in this and that invariant. > > Every time you say virtual in an API, you are creating a call > back hook. As an OS or API framework designer, you've got to > be real careful about that. You don't want users overriding > and hooking at any arbitrary point in an API, because you > cannot necessarily make those promises. And people may not > fully understand the promises they are making when they make > something virtual. > </quote> > > Herb Sutter also has an interesting article about virtual > methods, which is somewhat related: he says not to make > virtual functions public (or public functions virtual) [2]. > > Fabian > > [1] http://www.artima.com/intv/nonvirtual.html > [2] http://www.gotw.ca/publications/mill18.htm > > =================================== > This list is hosted by DevelopMentorR http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
