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

Reply via email to