Why do we really need 'virtual'?

[Thomas Eyde]

Why do we need 'virtual'? Doesn't the need for 'override' occure more often
than not? Why isn't there a 'sealed' instead, as this situation occure more
seldom?

The only reason I have found why 'virtual' is important, was in an article
which said something like: "...will force the developer to think ahead and
mark the method as overridable when necessary...". In .Net documentation I
have only found that one of the design goals is to aid the developer to not
introduce errors.

These statements are contradicting. Since when did most developer
successfully design a working and maintainable solution up front? Since when
did we successfully predict future needs and use? We have repeatidly
demonstrated that we are not good at predicting. So when a language force us
to think ahead, it actually helps us to introduce errors.

I can agree that we should express when we alter existing functionallity, so
marking a method with 'override' is probably a good thing, despite there is
no such thing as 'overload'.

I find it annoying everytime I do an 'override', I also have to look up the
base method and add a 'virtual'. It is annoying because it interrupts my
flow, but also because I am forced to change something that isn't changed.

Designing a method for extention is nothing we do by intention. It should be
by default. Designing a non extendable method, on the other hand, is
definitly by intention.

..thomas

[James]

If a base class exposes a signature and if all flags (whether or not it is
virtual) were set to (true) automatically override then methods with the
same signature could easily be mistaken as wanting to override when all they
where aiming to do was to create a new signature the same. If nothing else
it acts as a warning system.

--
James
http://www.software-dungeon.co.uk
..

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d452ce4@10.1.10.29...
> Why do we need 'virtual'? Doesn't the need for 'override' occure more
often
> than not? Why isn't there a 'sealed' instead, as this situation occure
more
> seldom?
>
> The only reason I have found why 'virtual' is important, was in an article
> which said something like: "...will force the developer to think ahead and
> mark the method as overridable when necessary...". In .Net documentation I
> have only found that one of the design goals is to aid the developer to
not
> introduce errors.
>
> These statements are contradicting. Since when did most developer
> successfully design a working and maintainable solution up front? Since
when
> did we successfully predict future needs and use? We have repeatidly
> demonstrated that we are not good at predicting. So when a language force
us
> to think ahead, it actually helps us to introduce errors.
>
> I can agree that we should express when we alter existing functionallity,
so
> marking a method with 'override' is probably a good thing, despite there
is
> no such thing as 'overload'.
>
> I find it annoying everytime I do an 'override', I also have to look up
the
> base method and add a 'virtual'. It is annoying because it interrupts my
> flow, but also because I am forced to change something that isn't changed.
>
> Designing a method for extention is nothing we do by intention. It should
be
> by default. Designing a non extendable method, on the other hand, is
> definitly by intention.
>
> .thomas
>
>

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d452ce4@10.1.10.29...
> Why do we need 'virtual'? Doesn't the need for 'override' occure more
often
> than not? Why isn't there a 'sealed' instead, as this situation occure
more
> seldom?
>
> The only reason I have found why 'virtual' is important, was in an article
> which said something like: "...will force the developer to think ahead and
> mark the method as overridable when necessary...". In .Net documentation I
> have only found that one of the design goals is to aid the developer to
not
> introduce errors.
>
> These statements are contradicting. Since when did most developer
> successfully design a working and maintainable solution up front? Since
when
> did we successfully predict future needs and use? We have repeatidly
> demonstrated that we are not good at predicting. So when a language force
us
> to think ahead, it actually helps us to introduce errors.
>
> I can agree that we should express when we alter existing functionallity,
so
> marking a method with 'override' is probably a good thing, despite there
is
> no such thing as 'overload'.
>
> I find it annoying everytime I do an 'override', I also have to look up
the
> base method and add a 'virtual'. It is annoying because it interrupts my
> flow, but also because I am forced to change something that isn't changed.
>
> Designing a method for extention is nothing we do by intention. It should
be
> by default. Designing a non extendable method, on the other hand, is
> definitly by intention.

I think I disagree fairly strongly.

If you don't design your class for extensibility - ie think about what
effect users overriding your function will have - then the only way that
extensibility works is by chance. Or it appears to work, but may fail in
some rare condition.

Virtual in C# makes a fairly strong statement. It says that the designer of
the class thought about how others would use and extend the class, and that
overriding this function is one way of doing it. Part of the contract of the
class is that overriding this function will work, and it's expected to do
so.

If virtual is the default, the statement is that overriding this method may
work, but that the designer may not have thought about that use, and it may
not work. There's no way to tell the difference between the two states.

It is true that with the C# approach, there will sometimes be classes that
could be extensible and work fine if only the designer had thought to make a
certain function virtual. I will gladly trade that for predictable classes
that work for what they say they will do; I'd rather re-invent the wheel
sometimes than not be sure whether I'm doing something that's officially
supported.

[Thomas Eyde]

"Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
news:3d45a1a6$1@10.1.10.29...
> Virtual in C# makes a fairly strong statement. It says that the designer
of
> the class thought about how others would use and extend the class, and
that
> overriding this function is one way of doing it. Part of the contract of
the
> class is that overriding this function will work, and it's expected to do
> so.

So how do I get a full overview of all the infinite ways to extend a class?
I don't have a functional crystal ball, so I have a hard time figuring out
what others actually might do.

Also, if I extend one of your class and do something odd, would you accept
the blame when my class fail to work? I would certainly not. Your code is
your responsibility, my code is mine.

What must a virtual method fulfill anyway to be guaranteed overridable?

..thomas

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d45d66b@10.1.10.29...
>
> "Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
> news:3d45a1a6$1@10.1.10.29...
> > Virtual in C# makes a fairly strong statement. It says that the designer
> of
> > the class thought about how others would use and extend the class, and
> that
> > overriding this function is one way of doing it. Part of the contract of
> the
> > class is that overriding this function will work, and it's expected to
do
> > so.
>
> So how do I get a full overview of all the infinite ways to extend a
class?
> I don't have a functional crystal ball, so I have a hard time figuring out
> what others actually might do.

The question isn't how others might want to extend the class, the question
is what ways you want people to extend the class.

> Also, if I extend one of your class and do something odd, would you accept
> the blame when my class fail to work? I would certainly not. Your code is
> your responsibility, my code is mine.

Well, it depends on what "something odd" is.

I think the question here is whether your code is more likely to work if you
know that the designer made something virtual expecting you to override it,
or whether the designer never thought of it.

It's pretty clear that the first case is more likely to work. As to whether
I take the blame, if I've made a function virtual, I think users of my class
have a reasonable expectation for them to be able to override it and do
mainline things without it breaking. Ideally, I should try to protect them
from doing bad things, but the effort to do this isn't always worth it; it
depends on the kind of code you're writing.

> What must a virtual method fulfill anyway to be guaranteed overridable?

I'm not sure I understand what your question is. If your question is what do
you have to do in class design to write a virtual that will work when it's
overridden, that depends tremendously on what your class does. Class-level
invariants are a fairly typical problem; my class does some processing,
calls one of my functions, does some more processing. If my function is
overridden, the function that's called could change my class state, making
it fail in subtle ways. Or an overridden function can forget to call my base
function, leaving the object in an incorrect state.

[Thomas Eyde]

"Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
news:3d46e70e$1@10.1.10.29...

> The question isn't how others might want to extend the class, the question
> is what ways you want people to extend the class.

This can equally be stated as how I *don't* want people to extend my class.
So I still prefer 'sealed' in favour of 'virtual'.

> I think the question here is whether your code is more likely to work if
you
> know that the designer made something virtual expecting you to override
it,
> or whether the designer never thought of it.

What if the designer forgot to mark it as virtual, or simply failed to see
something as extendable? I prefer to have the option to override and then
discover it doesn't work.

> I'm not sure I understand what your question is. If your question is what
do
> you have to do in class design to write a virtual that will work when it's
> overridden, that depends tremendously on what your class does. Class-level
> invariants are a fairly typical problem; my class does some processing,
> calls one of my functions, does some more processing. If my function is
> overridden, the function that's called could change my class state, making
> it fail in subtle ways. Or an overridden function can forget to call my
base
> function, leaving the object in an incorrect state.

You understood my question perfectly. I would argue that methods doing
complex processing are poor candidates for overriding in the first place.
Encapsulation would prevent me to see the complexity, but the method name
should hint about it. When I encounter such a method, I would have no desire
to change it in any ways. That would be to much work. I would rather take
its output and process it further.


You don't by chance have any samples or scenarios which supports the
decition that virtual is better than an opposite sealed? Do Java developer
report that their final should be replaced with virtual?


I find the enforced virtual annoying. I tend to move code up the inheritance
chain when I discover duplication, and down if it turns out it wasn't a
duplicate after all. To have to remember to add both virtual and override
slows me down.


..thomas

[Thomas Eyde]

"Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
news:3d45a1a6$1@10.1.10.29...

> Virtual in C# makes a fairly strong statement. It says that the designer
of
> the class thought about how others would use and extend the class, and
that
> overriding this function is one way of doing it. Part of the contract of
the
> class is that overriding this function will work, and it's expected to do
> so.

If the designer really did think about it. We have no guarantee he really
did.

> If virtual is the default, the statement is that overriding this method
may
> work, but that the designer may not have thought about that use, and it
may
> not work. There's no way to tell the difference between the two states.

I don't see why that is important. Java developers use final when they
decide that overriding is not permitted. Why isn't this a good idea?


..thomas

[Ovidiu Platon]

I may be a little OT here, but has anyone taken into account the versioning
system in .NET? I'm asking this question because everyone seems to think in
a Windows/C++(/Java) way.
I'm working now on a SoapExtension for a Web Service. For some reason, I've
decided to make my derived class sealed - it's all mine and nobody can mess
with it. However, as a smart developer, I'm supposed to be looking out for
extensibility - what if 50.0001% (or even fewer) of the people using my
class say "I wish I could have changed that behavior somehow"?
Well, it's simple: "I'll do that in version 2". If some people are happy
with my extension as it is, they can use version 1.x; others can use 2.x and
extend it in any way they want to. If I'm still not happy with version 2 of
my extension, I can make radical changes in version 3 and so on.
My point is that .NET is not COM. COM is dead. Really. No more **Don't touch
that interface, it's immutable**.
From this perspective, I think it's quite irrelevant whether we need
override more often than sealed and so on. We don't have to predict the
future, just develop components and rely on side-by-side versioning.
If you spot any flaws in my arguments, please post your comments.
Best regards,
Ovidiu.

[Thomas Eyde]

"Ovidiu Platon" <ovidiupl@microsoft-lab.pub.ro> wrote in message
news:3d48d728@10.1.10.29...
> If you spot any flaws in my arguments, please post your comments.

Good points. I have not tried out versioning, yet, but I have thought of the
possibility.

Versioning might solve our previous design mistakes, but I think my initial
question remains unanswered. I have been served good arguments on how it is
a good idea, but the arguments are not backed up with facts and/or examples.

I don't buy that simply marking a method with virtual will guarantee that
the designer really thought ahead and designed the method well. Yes,
thinking ahead is a good thing, but forcing us to do so does not improve the
quality of the thinking.

Related to 'virtual' is the use of 'override'. I don't understand why it is
important to know if one method overrides another. In VB.NET it is argued
that overloading an inherited method is important, in this case 'Overloads'
is enforced. In C# this is considered not important. An 'overload' modifyer
simply does not exist. Then why should 'override' be important?

..thomas

[Ovidiu Platon]

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d48e49e@10.1.10.29...
> I don't buy that simply marking a method with virtual will guarantee that
> the designer really thought ahead and designed the method well. Yes,
> thinking ahead is a good thing, but forcing us to do so does not improve
the
> quality of the thinking.
>

I don't think I can provide a recipe for the use of virtual (except for the
classic Shape example :) Imo, this would be the same as asking for immutable
software requirements, but there is no such thing. Software changes in time
and that's why I like the versioning system provided by .NET. Of course,
it's not a panacea, but I think it will help us a lot. You can go with the
flow, implement whatever you have to and, if necessary, take new
requirements into account and make changes in the next version. Or, as I
like to say, if you try to buy the best computer on the market, you'll never
get one.

> Related to 'virtual' is the use of 'override'. I don't understand why it
is
> important to know if one method overrides another. In VB.NET it is argued
> that overloading an inherited method is important, in this case
'Overloads'
> is enforced. In C# this is considered not important. An 'overload'
modifyer
> simply does not exist. Then why should 'override' be important?
>

'Override' is important for me, for readability reasons; as a C++ programmer
I actually found myself facing weird bugs a couple of times just because I
had fotgotten that I was dealing with a virtual method. Yes, there are some
extra keystrokes involved, but I think code is read many times more often
than it is written (since you only write it once :-)) I appreciate this
verbosity of C# even though there are more keywords/keystrokes involved.(I
don't like VB.NET otoh because of Me instead of this and some other similar
reasons).

Best regards,
Ovidiu.

[Zane Thomas]

"Thomas Eyde" <thomas.eyde@online.no> wrote:

>This can equally be stated as how I *don't* want people to extend my class.
>So I still prefer 'sealed' in favour of 'virtual'.

There are far more methods I don't want people to override than not, so I
prefer virtual.

>What if the designer forgot to mark it as virtual, or simply failed to see
>something as extendable?

Get a new designer.

>I prefer to have the option to override and then discover it doesn't work.

Discovery can often occur mysteriously (and undiscovered!) after
deployment. I'd rather not go down that road.

>I find the enforced virtual annoying. I tend to move code up the inheritance
>chain when I discover duplication, and down if it turns out it wasn't a
>duplicate after all. To have to remember to add both virtual and override
>slows me down.

Heh, maybe if you slowed down during design you'd more often put code in
the right place the first try. :-)


--

*--------={ Fine Art for .NET }=--------*
| .Net Components @ www.abderaware.com |
*---------------------------------------*

Turn on, tune in, download.
zane a@t abderaware.com

[Thomas Eyde]

"Zane Thomas" <zane@abderaware.com> wrote in message
news:3d4f0228.559530453@news.devx.com...
> There are far more methods I don't want people to override than not, so I
> prefer virtual.

When that's the case, shure. For me it's not. Should be interesting to see
some statistics on sealed vs virtual.

> Heh, maybe if you slowed down during design you'd more often put code in
> the right place the first try. :-)

Very few designs, if any, is perfect at the first try. More often than not,
it is first under implementation the design is really verifyed. So after I
finished the first part and started on the other I may discover similarity,
duplication, a pattern which was not obvious. And after staring the next
iteration I might discover some piece is more important or more fragile than
I thought, so I have to 'redesign'. There are many interrelations which are
nearly impossible to discover at designtime, or far easier to discover and
change at implementation time.

I also like to test out if a special design will work. If it includes
overriding, and it turns out it doesn't work after all, then I like it to be
easy to revert. Using a source code versioning system like Source Safe may
revert too much, or take too long compared to manual reverting.

..thomas

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d470dcf@10.1.10.29...
>
> "Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
> news:3d46e70e$1@10.1.10.29...
>
> > The question isn't how others might want to extend the class, the
question
> > is what ways you want people to extend the class.
>
> This can equally be stated as how I *don't* want people to extend my
class.
> So I still prefer 'sealed' in favour of 'virtual'.
>
> > I think the question here is whether your code is more likely to work if
> you
> > know that the designer made something virtual expecting you to override
> it,
> > or whether the designer never thought of it.
>
> What if the designer forgot to mark it as virtual, or simply failed to see
> something as extendable? I prefer to have the option to override and then
> discover it doesn't work.

The problem is when you discover it won't work. It might work on the version
you tested, but not work on the server version, or when you start using
another feature, or when there's a new release of the framework.

>
> > I'm not sure I understand what your question is. If your question is
what
> do
> > you have to do in class design to write a virtual that will work when
it's
> > overridden, that depends tremendously on what your class does.
Class-level
> > invariants are a fairly typical problem; my class does some processing,
> > calls one of my functions, does some more processing. If my function is
> > overridden, the function that's called could change my class state,
making
> > it fail in subtle ways. Or an overridden function can forget to call my
> base
> > function, leaving the object in an incorrect state.
>
> You understood my question perfectly. I would argue that methods doing
> complex processing are poor candidates for overriding in the first place.
> Encapsulation would prevent me to see the complexity, but the method name
> should hint about it. When I encounter such a method, I would have no
desire
> to change it in any ways. That would be to much work. I would rather take
> its output and process it further.
>
>
> You don't by chance have any samples or scenarios which supports the
> decition that virtual is better than an opposite sealed? Do Java developer
> report that their final should be replaced with virtual?

The problem with virtual by default is that it doesn't convey the intent of
the class author. A method may be virtual on purpose, or by accident. I
listed a few scenarios previously.

> I find the enforced virtual annoying. I tend to move code up the
inheritance
> chain when I discover duplication, and down if it turns out it wasn't a
> duplicate after all. To have to remember to add both virtual and override
> slows me down.

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d470f20@10.1.10.29...
>
> "Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
> news:3d45a1a6$1@10.1.10.29...
>
> > Virtual in C# makes a fairly strong statement. It says that the designer
> of
> > the class thought about how others would use and extend the class, and
> that
> > overriding this function is one way of doing it. Part of the contract of
> the
> > class is that overriding this function will work, and it's expected to
do
> > so.
>
> If the designer really did think about it. We have no guarantee he really
> did.
>
> > If virtual is the default, the statement is that overriding this method
> may
> > work, but that the designer may not have thought about that use, and it
> may
> > not work. There's no way to tell the difference between the two states.
>
> I don't see why that is important. Java developers use final when they
> decide that overriding is not permitted. Why isn't this a good idea?

Do they actually do this analysis for every method they write?

Oh, there's one consideration I didn't think about. There are some
optimizations that you can do with a normal method that you can't do with a
virtual method, so normal methods are slightly faster to call. They may also
result in small vtables for your objects.

[Eric Gunnerson]

I do agree that Side-by-side should address the "DLL ****" related issues,
but it doesn't address the issues that come up when I rebuild my app using
the new framework. If you've changed a bunch of interfaces on me, I'm not
going to be a happy camper. You've broken my code.

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Ovidiu Platon" <ovidiupl@microsoft-lab.pub.ro> wrote in message
news:3d48d728@10.1.10.29...
> I may be a little OT here, but has anyone taken into account the
versioning
> system in .NET? I'm asking this question because everyone seems to think
in
> a Windows/C++(/Java) way.
> I'm working now on a SoapExtension for a Web Service. For some reason,
I've
> decided to make my derived class sealed - it's all mine and nobody can
mess
> with it. However, as a smart developer, I'm supposed to be looking out for
> extensibility - what if 50.0001% (or even fewer) of the people using my
> class say "I wish I could have changed that behavior somehow"?
> Well, it's simple: "I'll do that in version 2". If some people are happy
> with my extension as it is, they can use version 1.x; others can use 2.x
and
> extend it in any way they want to. If I'm still not happy with version 2
of
> my extension, I can make radical changes in version 3 and so on.
> My point is that .NET is not COM. COM is dead. Really. No more **Don't
touch
> that interface, it's immutable**.
> From this perspective, I think it's quite irrelevant whether we need
> override more often than sealed and so on. We don't have to predict the
> future, just develop components and rely on side-by-side versioning.
> If you spot any flaws in my arguments, please post your comments.
> Best regards,
> Ovidiu.
>
>

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d48e49e@10.1.10.29...
> Related to 'virtual' is the use of 'override'. I don't understand why it
is
> important to know if one method overrides another. In VB.NET it is argued
> that overloading an inherited method is important, in this case
'Overloads'
> is enforced. In C# this is considered not important. An 'overload'
modifyer
> simply does not exist. Then why should 'override' be important?

Override is important because it conveys the intent of the designer. Here's
an example of what can happen:

class A
{
}

class B: A
{
virtual void Process();
}

that works, fine, but one day the provider of A ships a new class:

class A
{
virtual int Process();

public int StartProcess()
{
Process();
}
}

class B: A
{
virtual void Process();
}

What's the behavior of this? If you're using Java and you put in a new
version of A, with the added method, you've broken B. The class won't load
because of the type mismatch.

Even if you have the same return type, the call to Process in
A.StartProcess() will call B's function. That's clearly wrong, given that
A.Process() didn't exist when B.Process() was written.

[Mattias Sjögren]

Thomas,

>In VB.NET it is argued
>that overloading an inherited method is important, in this case 'Overloads'
>is enforced.

The Overloads keyword is perhaps one of the most misunderstood
features of VB.NET (probably because of bad naming). It has more to do
with name hiding than overloading.


>In C# this is considered not important. An 'overload' modifyer
>simply does not exist.

That's because the feature is lacking in C#. VB.NET gives you more
flexibility when it comes to overriding methods.


Mattias

===
Mattias Sjögren (VB MVP)
mattias @ mvps.org
http://www.msjogren.net/dotnet/

[Ovidiu Platon]

"Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
news:3d49923b$1@10.1.10.29...
> I do agree that Side-by-side should address the "DLL ****" related issues,
> but it doesn't address the issues that come up when I rebuild my app using
> the new framework. If you've changed a bunch of interfaces on me, I'm not
> going to be a happy camper. You've broken my code.
>
The idea was that with versioning you are not forced to rebuild the app
using the new framework. I know that by radically changing specs I can make
people miserable, and that's why I mentioned the 50% stuff: if you let other
developers' feedback drive you, you have pretty good chances of getting away
with it. The whole idea is not to repeat all the previous mistakes of other
people, such as CreateWindow/CreateWindowEx, WNDCLASS/WNDCLASSEX,
IDirectDraw/IDirectDraw2/... I don't like all that stuff. There must be a
better way, and the versioning system in .NET might be it.
Just imagine: with Windows 3.0 dlls you would have CreateWindow with its 11
parameters, with Windows 4.0 dll you would get CreateWindow with 12 params
and extra functionality. Do you need the extra UI functionality? Use v4.0 of
the assembly and that's it. It's difficult to do this when you have a huge
code base and you want to switch from v3 to v4, but this might be a good
thing after all: imo, instead of focusing on whether a method should be
virtual or not, developers should pay attention to proper component-oriented
design that would make these changes possible and feasible.
Best regards,
Ovidiu.

[Thomas Eyde]

"Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
news:3d4991cf$1@10.1.10.29...
> > I don't see why that is important. Java developers use final when they
> > decide that overriding is not permitted. Why isn't this a good idea?
>
> Do they actually do this analysis for every method they write?

Do C# developers actually do the counterpart analysis for every method they
write? Just enforcing a virtual is no guarantee for analysis. I think this
enhanced analysis is overrated.

> Oh, there's one consideration I didn't think about. There are some
> optimizations that you can do with a normal method that you can't do with
a
> virtual method, so normal methods are slightly faster to call. They may
also
> result in small vtables for your objects.

I am aware of that, but you said 'slightly faster'. Is it fast enough to do
the difference? The rules for optimation are:
1. Don't do it.
2. For experienced developers: Don't do it yet.

So when it is proved that my code is too slow, I will identify the
bottlenecks and fix it. I don't think the normal/virtual will be that
significant.

C# is better than Delphi at this point. Delphi has both virtual and dynamic
which is semanticly identical. One of them performs better when there are a
lot of overriding methods. I would say that predicing a future inheritance
hierarchy is near to impossible. I'm glad this feature didn't make it to C#.

Smaller vtables you say? I thought vtables was a COM thing? Then I actually
learned something today. How big is a vtable, and how many objects do I need
before the vtable size makes the difference?

[Thomas Eyde]

"Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
news:3d49911d$1@10.1.10.29...
> > What if the designer forgot to mark it as virtual, or simply failed to
see
> > something as extendable? I prefer to have the option to override and
then
> > discover it doesn't work.
>
> The problem is when you discover it won't work. It might work on the
version
> you tested, but not work on the server version, or when you start using
> another feature, or when there's a new release of the framework.

That is a problem. But testing should be done on something similar to the
production system, and then on the production system. And a new release of
the framework is always exciting. Sometimes it is designed to break previous
versions, sometimes not. Far fetched as it is, the VB6/VB.NET flamewars came
to mind.

I see you argue that forcing the developer to add 'virtual' is better,
because it helps to avoid mistakes. But we are only humans. I believe that
instead of thinking thing through, we often add the 'virtual', as otherwise
it won't compile.

..thomas

[James]

> Do C# developers actually do the counterpart analysis for every method
they
> write? Just enforcing a virtual is no guarantee for analysis. I think this
> enhanced analysis is overrated.

It's a design issue - and should be considered at the first stages of
component design. It is a very usefull feature when 20 different developers
have certain work to achieve before putting the project together.

--
James
http://www.software-dungeon.co.uk
..

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d4a2b12@10.1.10.29...
>
> "Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
> news:3d4991cf$1@10.1.10.29...
> > > I don't see why that is important. Java developers use final when they
> > > decide that overriding is not permitted. Why isn't this a good idea?
> >
> > Do they actually do this analysis for every method they write?
>
> Do C# developers actually do the counterpart analysis for every method
they
> write? Just enforcing a virtual is no guarantee for analysis. I think this
> enhanced analysis is overrated.
>
> > Oh, there's one consideration I didn't think about. There are some
> > optimizations that you can do with a normal method that you can't do
with
> a
> > virtual method, so normal methods are slightly faster to call. They may
> also
> > result in small vtables for your objects.
>
> I am aware of that, but you said 'slightly faster'. Is it fast enough to
do
> the difference? The rules for optimation are:
> 1. Don't do it.
> 2. For experienced developers: Don't do it yet.
>
> So when it is proved that my code is too slow, I will identify the
> bottlenecks and fix it. I don't think the normal/virtual will be that
> significant.
>
> C# is better than Delphi at this point. Delphi has both virtual and
dynamic
> which is semanticly identical. One of them performs better when there are
a
> lot of overriding methods. I would say that predicing a future inheritance
> hierarchy is near to impossible. I'm glad this feature didn't make it to
C#.
>
> Smaller vtables you say? I thought vtables was a COM thing? Then I
actually
> learned something today. How big is a vtable, and how many objects do I
need
> before the vtable size makes the difference?
>
>

[Thomas Eyde]

"Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
news:3d49933b$1@10.1.10.29...
> Override is important because it conveys the intent of the designer.
Here's
> an example of what can happen:

The first reply that pops out is: And overloads doesn't?

>
> class A
> {
> }
>
> class B: A
> {
> virtual void Process();
> }
>
> that works, fine, but one day the provider of A ships a new class:
>
> class A
> {
> virtual int Process();
>
> public int StartProcess()
> {
> Process();
> }
> }
>
> class B: A
> {
> virtual void Process();
> }
>
> What's the behavior of this? If you're using Java and you put in a new
> version of A, with the added method, you've broken B. The class won't load
> because of the type mismatch.

I see your point. But this applies only when A is in a different assembly
than B, doesn't it? I'm just asking, not implying that if so, then no
problem.

> Even if you have the same return type, the call to Process in
> A.StartProcess() will call B's function. That's clearly wrong, given that
> A.Process() didn't exist when B.Process() was written.

Please explain. How can A call anything in B? A doesn't know about B. But if
you mean that the new A would empower B to do B.StartProcess() I agree it
will call B.Process().

Intuitivly I say, of course, that's what I want. I want B's behaviour,
because that's my instance. If I wanted A's, I would create an instance of
A.

..thomas

[Thomas Eyde]

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:3d4998e0@10.1.10.29...
> The Overloads keyword is perhaps one of the most misunderstood
> features of VB.NET (probably because of bad naming). It has more to do
> with name hiding than overloading.

Maybe so. But you can't overload from a base class without using it, so for
the matter of coding, it is about overloading.

> >In C# this is considered not important. An 'overload' modifyer
> >simply does not exist.
>
> That's because the feature is lacking in C#.

That's what I said, wasn't it: feature lacking == does not exist

..thomas

[Thomas Eyde]

"James" <James@birdwire.co.uk> wrote in message news:3d4a2f95@10.1.10.29...
> > Do C# developers actually do the counterpart analysis for every method
> they
> > write? Just enforcing a virtual is no guarantee for analysis. I think
this
> > enhanced analysis is overrated.
>
> It's a design issue - and should be considered at the first stages of
> component design.

If it were 'sealed' instead of 'virtual', it would still be a design issue?

> It is a very usefull feature when 20 different developers
> have certain work to achieve before putting the project together.

You wouldn't put 20 developers on the same task, would you? I can picture
what 20 cooks would do if they prepared the same meal.

But if another developer create a component I need to fulfil my part, I
would use it as is, wouldn't I? If not, then:
The other developer didn't do his job. He made something unuseful.
- or -
I (or the analyst) didn't do my job. I failed to define the needed
functionallity
and the tests for verifying them.

..thomas

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d4a2b12@10.1.10.29...
>
> "Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
> news:3d4991cf$1@10.1.10.29...
> > > I don't see why that is important. Java developers use final when they
> > > decide that overriding is not permitted. Why isn't this a good idea?
> >
> > Do they actually do this analysis for every method they write?
>
> Do C# developers actually do the counterpart analysis for every method
they
> write? Just enforcing a virtual is no guarantee for analysis. I think this
> enhanced analysis is overrated.

No, I don't think C# developers do the analysis for every method they write;
that's my whole point. The C# behavior is that unless you specify virtual,
you don't get virtual behavior. The chance that the programmer has actually
thought about the ramifications of having a virtual method is surely higher
if they actually have to type 'virtual'.

>
> > Oh, there's one consideration I didn't think about. There are some
> > optimizations that you can do with a normal method that you can't do
with
> a
> > virtual method, so normal methods are slightly faster to call. They may
> also
> > result in small vtables for your objects.
>
> I am aware of that, but you said 'slightly faster'. Is it fast enough to
do
> the difference? The rules for optimation are:
> 1. Don't do it.
> 2. For experienced developers: Don't do it yet.
>
> So when it is proved that my code is too slow, I will identify the
> bottlenecks and fix it. I don't think the normal/virtual will be that
> significant.

These aren't programmer optimizations, they're JIT optimizations, and the
opportunities come up often enough that it makes sense for a JIT to make
them.

If your code is slow, you may be able to make changes to your code, but if
you're using a library that has tons of unneeded virtual functions, you may
not be able to do anything about it.

>
> C# is better than Delphi at this point. Delphi has both virtual and
dynamic
> which is semanticly identical. One of them performs better when there are
a
> lot of overriding methods. I would say that predicing a future inheritance
> hierarchy is near to impossible. I'm glad this feature didn't make it to
C#.
>
> Smaller vtables you say? I thought vtables was a COM thing? Then I
actually
> learned something today. How big is a vtable, and how many objects do I
need
> before the vtable size makes the difference?

vtables are a O-O thing. If you have polymorphism, you have to have some way
to figure out what function to call at runtime, and vtables are a common
implementation. The runtime has to track every virtual function as an
opportunity for specialization, so it has to provide the infrastructure to
do so.

The size question is hard to answer. Memory isn't as expensive as it used to
be, but processer cache sizes still have a big impact on execution speed, so
smaller is still better.

C++ had this same issue, except that since C++ has a compile-time
typesystem, it can make many of these optimizations even if functions are
virtual. C# and other systems that support dynamic loading can't do this,
because you can load at runtime a type that overrides a virtual function
that wasn't previously overridden.

>
>

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Ovidiu Platon" <ovidiupl@microsoft-lab.pub.ro> wrote in message
news:3d4a227d$1@10.1.10.29...
> "Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
> news:3d49923b$1@10.1.10.29...
> > I do agree that Side-by-side should address the "DLL ****" related
issues,
> > but it doesn't address the issues that come up when I rebuild my app
using
> > the new framework. If you've changed a bunch of interfaces on me, I'm
not
> > going to be a happy camper. You've broken my code.
> >
> The idea was that with versioning you are not forced to rebuild the app
> using the new framework.

Yes, you continue to use the old framework.

> I know that by radically changing specs I can make
> people miserable, and that's why I mentioned the 50% stuff: if you let
other
> developers' feedback drive you, you have pretty good chances of getting
away
> with it. The whole idea is not to repeat all the previous mistakes of
other
> people, such as CreateWindow/CreateWindowEx, WNDCLASS/WNDCLASSEX,
> IDirectDraw/IDirectDraw2/... I don't like all that stuff. There must be a
> better way, and the versioning system in .NET might be it.
> Just imagine: with Windows 3.0 dlls you would have CreateWindow with its
11
> parameters, with Windows 4.0 dll you would get CreateWindow with 12 params
> and extra functionality. Do you need the extra UI functionality? Use v4.0
of
> the assembly and that's it.
> It's difficult to do this when you have a huge
> code base and you want to switch from v3 to v4, but this might be a good
> thing after all: imo, instead of focusing on whether a method should be
> virtual or not, developers should pay attention to proper
component-oriented
> design that would make these changes possible and feasible.

I agree with that, and I think that .NET will be in a better situation than
Win32 in that regard.

I still think, however, that you shouldn't change your contract from version
to version. My experience is that customers are very unhappy when they have
to change their code while moving to a new release.

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d4a3041@10.1.10.29...
>
> "Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
> news:3d49933b$1@10.1.10.29...
> > Override is important because it conveys the intent of the designer.
> Here's
> > an example of what can happen:
>
> The first reply that pops out is: And overloads doesn't?
>
> >
> > class A
> > {
> > }
> >
> > class B: A
> > {
> > virtual void Process();
> > }
> >
> > that works, fine, but one day the provider of A ships a new class:
> >
> > class A
> > {
> > virtual int Process();
> >
> > public int StartProcess()
> > {
> > Process();
> > }
> > }
> >
> > class B: A
> > {
> > virtual void Process();
> > }
> >
> > What's the behavior of this? If you're using Java and you put in a new
> > version of A, with the added method, you've broken B. The class won't
load
> > because of the type mismatch.
>
> I see your point. But this applies only when A is in a different assembly
> than B, doesn't it? I'm just asking, not implying that if so, then no
> problem.

The same thing would happen if I owned both A and B, but presumably I'm
thinking of them both if I own them both, so in practice it wouldn't be an
issue.l

>
> > Even if you have the same return type, the call to Process in
> > A.StartProcess() will call B's function. That's clearly wrong, given
that
> > A.Process() didn't exist when B.Process() was written.
>
> Please explain. How can A call anything in B? A doesn't know about B. But
if
> you mean that the new A would empower B to do B.StartProcess() I agree it
> will call B.Process().
>
> Intuitivly I say, of course, that's what I want. I want B's behaviour,
> because that's my instance. If I wanted A's, I would create an instance of
> A.

The problem shows up when A calls StartProcess() itself to do some
processing, as part of some new functionality it added in the new version.
The designers said, "we have default behavior in StartProcess(), if you want
your own behavior, override it".

But B.StartProcess() was written before A started doing this, so it's really
unlikely that B.StartProcess() does the right thing.

[Eric Gunnerson]

--
Visit the C# product team at http://www.gotdotnet.com/team/csharp

This posting is provided "AS IS" with no warranties, and confers no rights.

"Thomas Eyde" <thomas.eyde@online.no> wrote in message
news:3d4a2bc0@10.1.10.29...
>
> "Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
> news:3d49911d$1@10.1.10.29...
> > > What if the designer forgot to mark it as virtual, or simply failed to
> see
> > > something as extendable? I prefer to have the option to override and
> then
> > > discover it doesn't work.
> >
> > The problem is when you discover it won't work. It might work on the
> version
> > you tested, but not work on the server version, or when you start using
> > another feature, or when there's a new release of the framework.
>
> That is a problem. But testing should be done on something similar to the
> production system, and then on the production system. And a new release of
> the framework is always exciting. Sometimes it is designed to break
previous
> versions, sometimes not. Far fetched as it is, the VB6/VB.NET flamewars
came
> to mind.
>
> I see you argue that forcing the developer to add 'virtual' is better,
> because it helps to avoid mistakes. But we are only humans. I believe that
> instead of thinking thing through, we often add the 'virtual', as
otherwise
> it won't compile.

I agree that this happens. But if I have 12 functions on my class and I do
this on one of them to get it to compile, surely I'm in a better state than
if all 12 of them are virtual by default.

[Thomas Eyde]

"Eric Gunnerson" <ericgu_nospam@microsoft.nospam.com> wrote in message
news:3d4ea132$1@10.1.10.29...

> The problem shows up when A calls StartProcess() itself to do some
> processing, as part of some new functionality it added in the new version.
> The designers said, "we have default behavior in StartProcess(), if you
want
> your own behavior, override it".
>
> But B.StartProcess() was written before A started doing this, so it's
really
> unlikely that B.StartProcess() does the right thing.

If A.StartProcess() has a different meaning than B.StartProcess(), then you
are probably right. B.StartProcess() will not do what A expects. But I
really don't care, as long as B.StartProcess() does what B expects. As long
as it does that, the code is not broken.