ADVANCED-DOTNET Digest - 7 Jul 2006 to 8 Jul 2006 (#2006-149)
ADVANCED-DOTNET Digest - 7 Jul 2006 to 8 Jul 2006 (#2006-149)
Table of contents:
Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET
(4)
Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET (4)
Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET
Re: Virtual methods in .NET - was Implementing an Interface - C# vs.
VB.NET (07/08)
From: Frans Bouma <[EMAIL PROTECTED]>
Re: Virtual methods in .NET - was Implementing an Interface - C# vs.
VB.NET (07/08)
From: Frans Bouma <[EMAIL PROTECTED]>
Re: Virtual methods in .NET - was Implementing an Interface - C# vs.
VB.NET (07/08)
From: Ian Griffiths <[EMAIL PROTECTED]>
Re: Virtual methods in .NET - was Implementing an Interface - C# vs.
VB.NET (07/08)
From: David Lanouette <[EMAIL PROTECTED]>
Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET
Re: Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET
(07/08)
From: Fabian Schmied <[EMAIL PROTECTED]>
Re: Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET
(07/08)
From: Stoyan Damov <[EMAIL PROTECTED]>
Re: Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET
(07/08)
From: Stoyan Damov <[EMAIL PROTECTED]>
Re: Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET
(07/08)
From: David Lanouette <[EMAIL PROTECTED]>
Browse the ADVANCED-DOTNET online archives.
From: Frans Bouma <[EMAIL PROTECTED]>
Subject: Re: Virtual methods in .NET - was Implementing an Interface - C#
vs. VB.NET
Date: Sat, 8 Jul 2006 08:59:06 +0200
> Virtual is default in VB.NET, not in C#...
No, it's not :)
FB
>
>
> Thanks,
>
> Shawn Wildermuth
> Wildermuth Consulting Services, LLC
> http://adoguy.com
> C# MVP, MCSD.NET, Author and Speaker
>
>
> > -----Original Message-----
> > From: Discussion of advanced .NET topics.
> > [mailto:[EMAIL PROTECTED] On Behalf Of David
> > Lanouette
> > Sent: Friday, July 07, 2006 7:37 PM
> > To: [email protected]
> > Subject: [ADVANCED-DOTNET] Virtual methods in .NET - was
> Implementing
> > an Interface - C# vs. VB.NET
> >
> > Anybody know why methods aren't virtual by default in .NET?
> > It seems like a really bad default to have all methods non-virtual.
> >
> >
> > ______________________________
> > - David Lanouette
> > - [EMAIL PROTECTED]
> >
> > "Excellence, then, is not an act, but a habit" - Aristotle
> >
> > ===================================
> > This list is hosted by DevelopMentor. 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
>
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
From: Frans Bouma <[EMAIL PROTECTED]>
Subject: Re: Virtual methods in .NET - was Implementing an Interface - C#
vs. VB.NET
Date: Sat, 8 Jul 2006 08:59:56 +0200
> Anybody know why methods aren't virtual by default in .NET?
> It seems like a really bad default to have all methods non-virtual.
Performance. If you have a call chain of n method calls and all
are virtual, it will be slower than when you have a call
chain of n method calls and all are non-virtual.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
From: Fabian Schmied <[EMAIL PROTECTED]>
Subject: Re: Virtual methods in .NET - was Implementing an Interface - C#
vs. VB.NET
Date: Sat, 8 Jul 2006 09:44:00 +0200
[...]
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 DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
From: Ian Griffiths <[EMAIL PROTECTED]>
Subject: Re: Virtual methods in .NET - was Implementing an Interface - C#
vs. VB.NET
Date: Sat, 8 Jul 2006 10:05:31 +0100
Virtual is a pretty bad default.
To make a method *usefully* overridable takes more than just marking it
virtual. You also need to come up with answers to questions like: should
the overriding method call the original base function, and if so, should
that be before, during, or after their replacement implementation? If
there are several overloads of the method available, are most of them
implemented in terms of other methods (a common technique), in which
case should the deriving class override just one method, and if so,
which is the one to override? Does the base class ever call this method
itself, and if so, under what conditions? (E.g. is there anything
peculiar like it gets called during construction?) Does the class have
some associated form of state machine (e.g. does it have multi-phase
construction?) and are there rules that relate the way the overridden
method is used or behaves with respect to that state machine? Are there
any peculiarities or quirks of this method that other code might be
relying on, and are these documented anywhere?
If you look at frameworks that have evolved over a long time, and which
make heavy use of inheritance, they always carry lots of scars from this
kind of decision. Windows Forms and WPF are two examples of this, WPF in
particular. (Probably because WPF has been evolving for so long.) The
documentation has loads of little notes describing considerations for
deriving classes, detailing the circumstances over which virtual methods
should be called, and what the rest of the framework or its clients will
be expecting. And this is in a framework where only a carefully selected
set of members are actually overridable. Indeed, in some cases they
split functionality in half, so you see pairs of methods, one containing
the replaceable bits of the logic, and the other containing the core
stuff you don't want to lose just because you overrode something.
It takes a lot of work and a lot of iterations to design a class
hierarchy where virtual methods work really well. So it should come as
no surprise that if you don't do any of this ground work, overriding
methods is going to be a pretty risky affair. Overriding a method that
wasn't designed with overriding in mind always runs the risk of removing
a chunk of important logic from the class. You've just cauterized part
of the object's brain - you'd better hope you can recreate whatever that
method was doing correctly.
And yet there's this persistent myth that if a method is virtual, it
will automatically be OK to derive it. This is naive wishful thinking.
(I think the performance thing is misleading by the way. Modern JVMs
detect when a particular call site always calls the same implementation
of a virtual function, and this enables them to optimize that method
call as though it were non-virtual. They can even inline virtual
function calls. So there's no overhead to using virtual functions in
Java unless you're actually exploiting their virtualness. The only
wrinkle in this story is that Java takes longer to get up to full speed
because of this - it detects monomorphic call sites at runtime, so it
can only perform this optimization after it has detected that. This
works great for servers where amortized average cost is the main thing.
It's not so great for UIs...)
The biggest problem today that keeps driving the (IMO) misguided demands
for making everything virtual is that virtual methods also happen to
look superficially attractive for an technique that really has nothing
to do with overriding methods provided by base classes: testability.
Indeed, that argument is very much the basis of this:
http://blogs.objectmentor.com/ArticleS.MichaelFeathers.ItsTimeToDeprecat
eFinal
Here Michael Feathers argues for banning 'final' (Java's keyword for
"not virtual", equivalent of 'sealed' in C#) entirely because it makes
testing hard. But to me, that article reads like a classic case of "if
all you've got is a hammer, everything looks like a nail" thinking. Yes,
testing final methods is awkward. But making everything virtual instead
is, drastic, clumsy, and dangerous.
I think there are preferable solutions. If the class you'd like to mock
for testing purposes happens to be a MarshalByRefObject, you can
generate a transparent proxy for the thing - an object which looks
exactly like the real thing (even returning the expected type from
GetType()) but which is in fact a fake under your control. That way you
get to mock the whole object without even deriving from it - no need to
own anything. This works brilliantly. The main problem is you can't
always use this technique because not everything derives from
MarshalByRefObject. But it does demonstrate pretty clearly that making
everything virtual is actually a pretty crude approach, and it's
certainly possible to envisage better alternatives.
So how could you mess with the build and test environment to create
similar solutions when dealing with non-MBROs? Well one obvious and
low-tech approach would be to build a class that looks just like the
thing you want to mock, and compile against that rather than the real
thing. (You'd want to generate this mock of course - it'd be tedious to
write by hand.) There are numerous logistical challenges here, which I
suspect is one reason you don't see this much. It's just so much easier
to do everything through interfaces, even though that's barely any more
elegant than the "everything virtual whether it makes sense or not"
style.
--
Ian Griffiths - Pluralsight
http://www.interact-sw.co.uk/iangblog/
-----Original Message-----
From: David Lanouette
Sent: 08 July 2006 00:37
Anybody know why methods aren't virtual by default in .NET? It seems
like a really bad default to have all methods non-virtual.
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
From: Stoyan Damov <[EMAIL PROTECTED]>
Subject: Re: Virtual methods in .NET - was Implementing an Interface - C#
vs. VB.NET
Date: Sat, 8 Jul 2006 14:59:14 +0300
I already said that and also said that if an application "suffers"
(mwuaha :) a performance hit from the very fact that it calls virtual
methods, it shouldn't be written for .NET.
On 7/8/06, Frans Bouma <[EMAIL PROTECTED]> wrote:
> Anybody know why methods aren't virtual by default in .NET?
> It seems like a really bad default to have all methods non-virtual.
Performance. If you have a call chain of n method calls and all
are virtual, it will be slower than when you have a call
chain of n method calls and all are non-virtual.
FB
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
Cheers,
Stoyan
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
From: David Lanouette <[EMAIL PROTECTED]>
Subject: Re: Virtual methods in .NET - was Implementing an Interface - C#
vs. VB.NET
Date: Sat, 8 Jul 2006 09:27:15 -0400
Just looked in the SDK docs. From the VB Language Reference section on the
Function keyword
...
Overridable
Optional. Indicates that this Function procedure can be overridden by an
identically named procedure in a derived class. Overridable is the default
setting for a procedure that itself overrides a base class procedure.
NotOverridable
Optional. Indicates that this Function procedure cannot be overridden in a
derived class. NotOverridable is the default setting for a procedure that
does not itself override a base class procedure.
...
So it seems that VB doesn't default to virtual, unless it's overriding an
existing method.
______________________________
- 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 Frans Bouma
> Sent: Saturday, July 08, 2006 2:59 AM
> To: [email protected]
> Subject: Re: [ADVANCED-DOTNET] Virtual methods in .NET - was
> Implementing an Interface - C# vs. VB.NET
>
> > Virtual is default in VB.NET, not in C#...
>
> No, it's not :)
>
> FB
>
> >
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
From: Stoyan Damov <[EMAIL PROTECTED]>
Subject: Re: Virtual methods in .NET - was Implementing an Interface - C#
vs. VB.NET
Date: Sat, 8 Jul 2006 17:51:24 +0300
[ranting]
Never used VB.NET and I'm pretty sure I'll never use it. Microsoft had
the unique chance to design it right this time (as they scrapped the
old VB anyway) and still managed to fubar it with all these new
keywords, "features" and silent defaults. No offence here to any
VB.NET programmers and I don't want to start any religious wars here,
but IMVHO VB.NET is the dumbest (and not needed) programming language
on earth. While I still think VB (6) was really useful for quick
testing C++ COM components and for building semi-complex UI-intensive
apps, VB.NET is useless when there's C#.
On 7/8/06, David Lanouette <[EMAIL PROTECTED]> wrote:
Just looked in the SDK docs. From the VB Language Reference section on
the
Function keyword
...
Overridable
Optional. Indicates that this Function procedure can be overridden by an
identically named procedure in a derived class. Overridable is the default
setting for a procedure that itself overrides a base class procedure.
NotOverridable
Optional. Indicates that this Function procedure cannot be overridden in a
derived class. NotOverridable is the default setting for a procedure that
does not itself override a base class procedure.
...
So it seems that VB doesn't default to virtual, unless it's overriding an
existing method.
______________________________
- 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 Frans Bouma
> Sent: Saturday, July 08, 2006 2:59 AM
> To: [email protected]
> Subject: Re: [ADVANCED-DOTNET] Virtual methods in .NET - was
> Implementing an Interface - C# vs. VB.NET
>
> > Virtual is default in VB.NET, not in C#...
>
> No, it's not :)
>
> FB
>
> >
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
Cheers,
Stoyan
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
From: David Lanouette <[EMAIL PROTECTED]>
Subject: Re: Virtual methods in .NET - was Implementing an Interface - C#
vs. VB.NET
Date: Sat, 8 Jul 2006 12:07:26 -0400
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: [email protected]
> 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
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
