Isn't the main reason for making methods non-virtual by default supposed to prevent unanticipated overrides? When authoring a class that others are supposed to derive from you have to be strategic about which methods are to be overridable or else you can get versioning and other problems. Especially if it is black-boxed. In my experience virtual methods should basically be empty to avoid the problem with "should/must I call the base implementation or not, do I call it before or after my code etc".
// Kristofer -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Frans Bouma Sent: den 26 februari 2007 09:45 To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET > As I said the profiling API is not an optimal way of doing things (in > particulaer because there is no good way of updating symbols on the > fly). Doing a byte coe weave (link time) one can quite easily update > symbols for ven code. Ok, I then misinterpreted your post, I thought you prefered the profiler api to do things. > My statement that it offers more hope is contingent upon a mechanism > to update symbols, ifthis existed it would really offer the best > ofboth worlds. fully agreed. About SSCLI modified tools: these can be helpful, but it should be doable with standard MS shipped .NET code/compilers, as most organisations won't trust a '3rd party compiler' I think. FB =================================== This list is hosted by DevelopMentor(r) 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