Hi all,
In which circumstances it is appropriate to declare methods as non-virtual?
Thanx,
Adrian.
32  4457 
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi all,
In which circumstances it is appropriate to declare methods as
non-virtual?
Any time that a) security could be comprimised, b)stability could be
comprimised, c) its not possible to write a method that cannot be overriden
safely(related to a &b both).
Thanx,
Adrian.
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi all,
In which circumstances it is appropriate to declare methods as
non-virtual?
Any time that a) security could be comprimised, b)stability could be
comprimised, c) its not possible to write a method that cannot be overriden
safely(related to a &b both).
Thanx,
Adrian.
Anytime you want that the base class method to remain unchanged by
overwriting it in inheritors.
:) I presume you came from Java where all the methods are virtual by
default, anyway it adds some clarity to the code.
--
Horatiu Ripa
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:#y**************@TK2MSFTNGP09.phx.gbl... Hi all,
In which circumstances it is appropriate to declare methods as
non-virtual?
Thanx,
Adrian.
Anytime you want that the base class method to remain unchanged by
overwriting it in inheritors.
:) I presume you came from Java where all the methods are virtual by
default, anyway it adds some clarity to the code.
--
Horatiu Ripa
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:#y**************@TK2MSFTNGP09.phx.gbl... Hi all,
In which circumstances it is appropriate to declare methods as
non-virtual?
Thanx,
Adrian.
Adrian Herscu <bm*****@hotmail.com> wrote: In which circumstances it is appropriate to declare methods as non-virtual?
Well, they're non-virtual by default, normally. The only time when you
need to make them specifically non-virtual is when you're overriding a
virtual method, but you don't want anyone to override your
implementation.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Horatiu Ripa" <un****@businessco.us> wrote in message
news:ew*************@TK2MSFTNGP11.phx.gbl... Anytime you want that the base class method to remain unchanged by
overwriting it in inheritors.
:) I presume you came from Java where all the methods are virtual by
default, anyway it adds some clarity to the code.
--
Horatiu Ripa
You almost guess it right! I learn Java a few days before, and it says that
it is C++ cleaned up. As far as I remember, C++ has virtual and non-virtual
method declarations and now I see that C# continued that tradition. But, I
want to understand the essence of it - why non-virtual methods are needed?
Java is used almost ten years without non-virtual methods and nobody
complains about!
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:#y**************@TK2MSFTNGP09.phx.gbl... Hi all,
In which circumstances it is appropriate to declare methods as
non-virtual?
Thanx,
Adrian.
Adrian Herscu <bm*****@hotmail.com> wrote: You almost guess it right! I learn Java a few days before, and it says that
it is C++ cleaned up. As far as I remember, C++ has virtual and non-virtual
method declarations and now I see that C# continued that tradition. But, I
want to understand the essence of it - why non-virtual methods are needed?
Java is used almost ten years without non-virtual methods and nobody
complains about!
Java *does* have non-virtual methods (they're called final in Java).
Look at Object.wait() for example.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
One common use is with the "Template Method" pattern:
the base class declares a public non-virtual function which
checks preconditions, calls a protected or private virtual
function, then checks postconditions, like so:
(F is non-virtual, DoF is protected virtual and probably abstract)
int base::F(int i)
{
int ret;
if (IsParamInRange(i))
ret = DoF(i);
if (IsRetInRange(ret))
return ret;
else
return someError;
}
The idea is to force everyone to use a common "entry point"
to some functionality with derived classes implementing specific
tasks.
Andrew
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi all,
In which circumstances it is appropriate to declare methods as
non-virtual?
Thanx,
Adrian.
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ... Adrian Herscu <bm*****@hotmail.com> wrote: You almost guess it right! I learn Java a few days before, and it says
that it is C++ cleaned up. As far as I remember, C++ has virtual and
non-virtual method declarations and now I see that C# continued that tradition. But,
I want to understand the essence of it - why non-virtual methods are
needed? Java is used almost ten years without non-virtual methods and nobody
complains about!
Java *does* have non-virtual methods (they're called final in Java).
Look at Object.wait() for example.
I think you are wrong. Read the Java Language Specification, para 8.4.3.3:
"A method can be declared final to prevent subclasses from overriding or
hiding it. It is a compile-time error to attempt to override or hide a final
method".
A final method in Java is close to a sealed method in C# - it prevents
further overriding.
In Java, methods can be hidden only by static methods - so, Java has no
concept of non-virtual methods.
While in C#, methods can be hidden because they were not marked virtual -
so, in order to be sealed a method has to be virtual.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
That's interesting - other examples?
"andrew queisser" <an*************@hp.com> wrote in message
news:3f********@usenet01.boi.hp.com... One common use is with the "Template Method" pattern:
the base class declares a public non-virtual function which
checks preconditions, calls a protected or private virtual
function, then checks postconditions, like so:
(F is non-virtual, DoF is protected virtual and probably abstract)
int base::F(int i)
{
int ret;
if (IsParamInRange(i))
ret = DoF(i);
if (IsRetInRange(ret))
return ret;
else
return someError;
}
The idea is to force everyone to use a common "entry point"
to some functionality with derived classes implementing specific
tasks.
Andrew
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi all,
In which circumstances it is appropriate to declare methods as
non-virtual?
Thanx,
Adrian.
Adrian Herscu <bm*****@hotmail.com> wrote: Java *does* have non-virtual methods (they're called final in Java).
Look at Object.wait() for example.
I think you are wrong. Read the Java Language Specification, para 8.4.3.3:
"A method can be declared final to prevent subclasses from overriding or
hiding it. It is a compile-time error to attempt to override or hide a final
method".
A final method in Java is close to a sealed method in C# - it prevents
further overriding.
And that, as far as I'm concerned, is the principal feature of being
non-virtual.
In Java, methods can be hidden only by static methods - so, Java has no
concept of non-virtual methods.
No, it has no concept of instance methods hiding other instance
methods, which I view as being separate from having no concept of non-
virtual methods.
While in C#, methods can be hidden because they were not marked virtual -
so, in order to be sealed a method has to be virtual.
In my view, they can be sealed to prevent them being virtual any
further.
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
It's all a matter of definition, of course, but mine seems to fit in
pretty well with this section from the MSDN on virtual members:
<quote>
The virtual keyword is used to modify a method or property declaration,
in which case the method or the property is called a virtual member.
The implementation of a virtual member can be changed by an overriding
member in a derived class.
When a virtual method is invoked, the run-time type of the object is
checked for an overriding member. The overriding member in the most
derived class is called, which might be the original member, if no
derived class has overridden the member. (For more information on run-
time type and most derived implementation, see 10.5.3 Virtual methods.)
By default, methods are non-virtual. You cannot override a non-virtual
method.
</quote>
Here's another one, from the C# language specification:
<quote>
The implementation of a non-virtual method is invariant: The
implementation is the same whether the method is invoked on an instance
of the class in which it is declared or an instance of a derived class.
In contrast, the implementation of a virtual method can be superseded
by derived classes.
</quote>
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I can't give you a good explanation of that. Especially because you can
"overwrite" a method even if it is not declared virtual in the base class
(by declaring a method with the same name an params in the child with "new")
and having the same behaviour. Probably the binding mechanisms take some
advantages of it, but it is just a supposition, I didn't explore this issue.
Another questions is "why not?". Anyhow I find it good as long as the code
is more readable and understandable, when you see the "override" keyword in
a method decalaration it is clear that it overrides/implements a method of a
base class.
Where?
1. In polymorphic structures, where the base class contains some common
behaviour/property that is the same for the derrived classes i.e.:
- shape (base) with circle, square, triangle (derrived): a setColor() method
is the same for all the shapes
2. In classes that contains general behaviours, when you want the derrived
classes only to extend the behaviours and not to change any of the base
behaviours i.e.:
- humanBeing (base) that contains goToSleep(), awake(), walk(), jump(),
stay(); women derrived from humanBeing that contains talkTooMuch(),
spendMensIncome() and man that contains watchAllSportAtTV(),
seekOtherWomen() and so on... :))
Anyhow you can do that explicitly by marking the methods as "sealed", and ,
as I already wrote, you can trick that.
--
Horatiu Ripa
Software Development Manager
Business Logic Systems LTD
21 Victor Babes str., 1st floor, 3400 Cluj-Napoca, Romania
Phone/Fax: +40 264 590703
Web: www.businesslogic.co.uk
This email (email message and any attachments) is strictly confidential,
possibly privileged and is intended solely for the person or organization to
whom it is addressed. If you are not the intended recipient, you must not
copy, distribute or take any action in reliance on it. If you have received
this email in error, please inform the sender immediately before deleting
it. Business Logic Systems Ltd accepts no responsibility for any advice,
opinion, conclusion or other information contained in this email or arising
from its disclosure.
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:ew*************@TK2MSFTNGP10.phx.gbl... That's interesting - other examples?
"andrew queisser" <an*************@hp.com> wrote in message
news:3f********@usenet01.boi.hp.com... One common use is with the "Template Method" pattern:
the base class declares a public non-virtual function which
checks preconditions, calls a protected or private virtual
function, then checks postconditions, like so:
(F is non-virtual, DoF is protected virtual and probably abstract)
int base::F(int i)
{
int ret;
if (IsParamInRange(i))
ret = DoF(i);
if (IsRetInRange(ret))
return ret;
else
return someError;
}
The idea is to force everyone to use a common "entry point"
to some functionality with derived classes implementing specific
tasks.
Andrew
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi all,
In which circumstances it is appropriate to declare methods as
non-virtual?
Thanx,
Adrian.
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Adrian Herscu <bm*****@hotmail.com> wrote: Java *does* have non-virtual methods (they're called final in Java).
Look at Object.wait() for example.
I think you are wrong. Read the Java Language Specification, para
8.4.3.3: "A method can be declared final to prevent subclasses from overriding or
hiding it. It is a compile-time error to attempt to override or hide a
final method".
A final method in Java is close to a sealed method in C# - it prevents
further overriding.
And that, as far as I'm concerned, is the principal feature of being
non-virtual.
No - the principal feature of being non-virtual, is that non-virtual methods
are resolved at compile-time (a.k.a. static or early binding), so a call
*always* executes the same implementation.
In Java, methods can be hidden only by static methods - so, Java has no
concept of non-virtual methods.
No, it has no concept of instance methods hiding other instance
methods, which I view as being separate from having no concept of non-
virtual methods.
Think again. *Only* non-virtual methods can be "hidden".
While in C#, methods can be hidden because they were not marked
virtual - so, in order to be sealed a method has to be virtual.
In my view, they can be sealed to prevent them being virtual any
further.
"...virtual any further" = "...overriden any further"
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
It's all a matter of definition, of course, but mine seems to fit in
pretty well with this section from the MSDN on virtual members:
<quote>
The virtual keyword is used to modify a method or property declaration,
in which case the method or the property is called a virtual member.
The implementation of a virtual member can be changed by an overriding
member in a derived class.
When a virtual method is invoked, the run-time type of the object is
checked for an overriding member. The overriding member in the most
derived class is called, which might be the original member, if no
derived class has overridden the member. (For more information on run-
time type and most derived implementation, see 10.5.3 Virtual methods.)
By default, methods are non-virtual. You cannot override a non-virtual
method.
</quote>
OK - but you can still hide it.
Here's another one, from the C# language specification:
<quote>
The implementation of a non-virtual method is invariant: The
implementation is the same whether the method is invoked on an instance
of the class in which it is declared or an instance of a derived class.
In contrast, the implementation of a virtual method can be superseded
by derived classes.
</quote>
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
A final method in Java absolutely does *not* satisfy the descriptions of
non-virtual methods above - simply because you cannot hide it as you can in
C#. Moreover, even a C# "sealed" method which is the most close to a Java
"final" method, can be hidden by further subclasses
There are two separate notions:
1) Overriding - by overriding, a subclass replaces method pointers in
object's v-table and since all method invokations are made through that
v-table, you will always get the overriding implementation no matter from
which site you call it (either from superclass' site or from subclass'
site) - hence, dynamic binding. Also, that's the reason for naming those
methods "virtual" - because their implementation is not known until
run-time.
2) Hidding - this is a totally different mechanism: method invokations are
resolved during compile-time (static binding); so, there is no v-table to go
through - the call is direct.
In summary: when you call a non-virtual method, you will _always_ get the
same implementation executed; when you call a virtual method, you will *not*
always get the same implementation executed - it depends on the overriding
subclasses.
//++ run this test ++++++
using System;
class A {
public void M1() {
Console.WriteLine("A::M1");
}
virtual public void M2() {
Console.WriteLine("A::M2");
}
}
class B : A {
new public void M1() {
Console.WriteLine("B::M1 - I'm hidding A::M1");
}
// only virtual methods can be sealed
sealed override public void M2() {
Console.WriteLine("B::M2 - I'm overriding A::M2");
}
}
class C : B {
new public void M1() {
Console.WriteLine("C::M1 - I'm hidding B::M1");
}
// still can hide (virtually!) the sealed base
new virtual public void M2() {
Console.WriteLine("C::M2 - I'm hidding B::M2, since it is sealed");
}
}
class TestDerivation {
static void Main() {
A objA;
objA = new A();
objA.M1();
objA.M2();
objA = new B();
objA.M1(); // non-virtual - A::M1 implementation will execute
objA.M2(); // virtual - B::M2 implementation will execute
objA = new C();
objA.M1(); // non-virtual - A::M1 implementation will execute
objA.M2(); // virtual and sealed at B class level
// - B::M2 implementation will execute
}
}
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi, Java *does* have non-virtual methods (they're called final in Java).
Look at Object.wait() for example.
I think you are wrong. Read the Java Language Specification, para
8.4.3.3: "A method can be declared final to prevent subclasses from overriding or
hiding it. It is a compile-time error to attempt to override or hide a
final method".
A final method in Java is close to a sealed method in C# - it prevents
further overriding.
And that, as far as I'm concerned, is the principal feature of being
non-virtual.
I don't know how is in JAVA, but if you assert here that declaring a method
as *sealed* si the same as declaring non-virtual method you are wrong. Such
a method is still virtulal.
class A
{
public virtual void f()
{
}
}
class B: A
{
public override void f()
{
}
}
class C: B
{
public override sealed void f();
{
}
}
A a = new C()
a.f() calls C.f()
Isn't it virtual? If it wasn't it would call A.f()
*sealed* modifier force you to stop using overriden until you don't use
*virtual* again and then you can continue override the method. BTW the
compiler generates *callvirt* instruction as a evidence of that the method
is indeed *virtual*
While in C#, methods can be hidden because they were not marked
virtual - so, in order to be sealed a method has to be virtual.
In my view, they can be sealed to prevent them being virtual any
further.
In c# you can keep going with overrideing the method which was sealed. what
you have to is to declared it as virtual again(to start new virtual
implemetation).
That is posible because when CLR decides, which is most-derived method it
doesn't take into account only the runtime type of the object it kind of
takes into account the type of the variable as well.
To be more strict
callvirt is provided with the name of the class from where to start looking
for the most-derived implementation.
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
When you put *sealed* modifier for a method you have to put override as well
(other wise it does'n make sence to prohibit overriding of something which
cannot be overrided anyway). The modifier *override* already means that the
method is virtual.
It's all a matter of definition, of course, but mine seems to fit in
pretty well with this section from the MSDN on virtual members:
<quote>
The virtual keyword is used to modify a method or property declaration,
in which case the method or the property is called a virtual member.
The implementation of a virtual member can be changed by an overriding
member in a derived class.
When a virtual method is invoked, the run-time type of the object is
checked for an overriding member. The overriding member in the most
derived class is called, which might be the original member, if no
derived class has overridden the member. (For more information on run-
time type and most derived implementation, see 10.5.3 Virtual methods.)
By default, methods are non-virtual. You cannot override a non-virtual
method.
</quote>
If you read further down the same section you will find example of hiding
virtual methods, which is more closely to what happend when you declare a
method as a *sealed*. *sealed* modifier just force you to hide the method if
you want to change the implementation.
Here's another one, from the C# language specification:
<quote>
The implementation of a non-virtual method is invariant: The
implementation is the same whether the method is invoked on an instance
of the class in which it is declared or an instance of a derived class.
In contrast, the implementation of a virtual method can be superseded
by derived classes.
</quote>
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
If *final* in JAVA means that the method cannod be overriden or hid then it
is different form the non-virtual methods.
Non-virtual methods cannot be overriden - OK. One can hide then, though.
So my question is: Why C# allows virtual methods to be hidden. Isn't it
error prone.
I believe that the best is:
1. To have virtual and non-virtual methods.
2. Sealing virtual methods has to prevent further overriding and hiding the
methods.
And actually I think I know the answer. It is side efect of the way the CLR
resolves wich is the most-derived method. .NET is cross langage platform and
if C# was preventing this using calsses written in other languges (allowing
hiding virtual methods) would put C# programmers to consfusion.
B\rgds
100
Hi, Java *does* have non-virtual methods (they're called final in Java).
Look at Object.wait() for example.
I think you are wrong. Read the Java Language Specification, para
8.4.3.3: "A method can be declared final to prevent subclasses from overriding or
hiding it. It is a compile-time error to attempt to override or hide a
final method".
A final method in Java is close to a sealed method in C# - it prevents
further overriding.
And that, as far as I'm concerned, is the principal feature of being
non-virtual.
I don't know how is in JAVA, but if you assert here that declaring a method
as *sealed* si the same as declaring non-virtual method you are wrong. Such
a method is still virtulal.
class A
{
public virtual void f()
{
}
}
class B: A
{
public override void f()
{
}
}
class C: B
{
public override sealed void f();
{
}
}
A a = new C()
a.f() calls C.f()
Isn't it virtual? If it wasn't it would call A.f()
*sealed* modifier force you to stop using overriden until you don't use
*virtual* again and then you can continue override the method. BTW the
compiler generates *callvirt* instruction as a evidence of that the method
is indeed *virtual*
While in C#, methods can be hidden because they were not marked
virtual - so, in order to be sealed a method has to be virtual.
In my view, they can be sealed to prevent them being virtual any
further.
In c# you can keep going with overrideing the method which was sealed. what
you have to is to declared it as virtual again(to start new virtual
implemetation).
That is posible because when CLR decides, which is most-derived method it
doesn't take into account only the runtime type of the object it kind of
takes into account the type of the variable as well.
To be more strict
callvirt is provided with the name of the class from where to start looking
for the most-derived implementation.
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
When you put *sealed* modifier for a method you have to put override as well
(other wise it does'n make sence to prohibit overriding of something which
cannot be overrided anyway). The modifier *override* already means that the
method is virtual.
It's all a matter of definition, of course, but mine seems to fit in
pretty well with this section from the MSDN on virtual members:
<quote>
The virtual keyword is used to modify a method or property declaration,
in which case the method or the property is called a virtual member.
The implementation of a virtual member can be changed by an overriding
member in a derived class.
When a virtual method is invoked, the run-time type of the object is
checked for an overriding member. The overriding member in the most
derived class is called, which might be the original member, if no
derived class has overridden the member. (For more information on run-
time type and most derived implementation, see 10.5.3 Virtual methods.)
By default, methods are non-virtual. You cannot override a non-virtual
method.
</quote>
If you read further down the same section you will find example of hiding
virtual methods, which is more closely to what happend when you declare a
method as a *sealed*. *sealed* modifier just force you to hide the method if
you want to change the implementation.
Here's another one, from the C# language specification:
<quote>
The implementation of a non-virtual method is invariant: The
implementation is the same whether the method is invoked on an instance
of the class in which it is declared or an instance of a derived class.
In contrast, the implementation of a virtual method can be superseded
by derived classes.
</quote>
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
If *final* in JAVA means that the method cannod be overriden or hid then it
is different form the non-virtual methods.
Non-virtual methods cannot be overriden - OK. One can hide then, though.
So my question is: Why C# allows virtual methods to be hidden. Isn't it
error prone.
I believe that the best is:
1. To have virtual and non-virtual methods.
2. Sealing virtual methods has to prevent further overriding and hiding the
methods.
And actually I think I know the answer. It is side efect of the way the CLR
resolves wich is the most-derived method. .NET is cross langage platform and
if C# was preventing this using calsses written in other languges (allowing
hiding virtual methods) would put C# programmers to consfusion.
B\rgds
100
"Horatiu Ripa" <un****@businessco.us> wrote in message
news:e8**************@TK2MSFTNGP12.phx.gbl... I can't give you a good explanation of that. Especially because you can
"overwrite" a method even if it is not declared virtual in the base class
(by declaring a method with the same name an params in the child with
"new") and having the same behaviour. Probably the binding mechanisms take some
advantages of it, but it is just a supposition, I didn't explore this
issue. Another questions is "why not?". Anyhow I find it good as long as the code
is more readable and understandable, when you see the "override" keyword
in a method decalaration it is clear that it overrides/implements a method of
a base class.
I've already explained what's the difference between "overriding" and
"hidding",
and it is not superficial.
Where?
1. In polymorphic structures, where the base class contains some common
behaviour/property that is the same for the derrived classes i.e.:
- shape (base) with circle, square, triangle (derrived): a setColor()
method is the same for all the shapes
OK - some "setColor(int32)" method is implemented the same across the
derivation tree.
So what? What advantage I'm gaining by implementing this method as
non-virtual?
The only advantage I can see, is some increased performance (because the
call goes
direcly to the method implementation and not through a v-table).
And by the way, a typical implementation of "setColor(int32)" will probably
look like:
this.color = iColor; hardly an algorithm, so it couldn't be expected to
change much
across the derivation tree anyway.
2. In classes that contains general behaviours, when you want the derrived
classes only to extend the behaviours and not to change any of the base
behaviours i.e.:
- humanBeing (base) that contains goToSleep(), awake(), walk(), jump(),
stay(); women derrived from humanBeing that contains talkTooMuch(),
spendMensIncome() and man that contains watchAllSportAtTV(),
seekOtherWomen() and so on... :))
I'm not sure about this example as well. A human being does "goToSleep()",
but
men and women can do it differently - a men will go to sleep without
brushing his teeth.
Anyhow you can do that explicitly by marking the methods as "sealed", and
, as I already wrote, you can trick that.
As I've already said, "sealed" methods can still be hidden (unlike Java's
"final") -
so a "sealed" method is just a non-virtual method.
--
Horatiu Ripa
Software Development Manager
Business Logic Systems LTD
21 Victor Babes str., 1st floor, 3400 Cluj-Napoca, Romania
Phone/Fax: +40 264 590703
Web: www.businesslogic.co.uk
This email (email message and any attachments) is strictly confidential,
possibly privileged and is intended solely for the person or organization
to whom it is addressed. If you are not the intended recipient, you must not
copy, distribute or take any action in reliance on it. If you have
received this email in error, please inform the sender immediately before deleting
it. Business Logic Systems Ltd accepts no responsibility for any advice,
opinion, conclusion or other information contained in this email or
arising from its disclosure.
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:ew*************@TK2MSFTNGP10.phx.gbl... That's interesting - other examples?
"andrew queisser" <an*************@hp.com> wrote in message
news:3f********@usenet01.boi.hp.com... One common use is with the "Template Method" pattern:
the base class declares a public non-virtual function which
checks preconditions, calls a protected or private virtual
function, then checks postconditions, like so:
(F is non-virtual, DoF is protected virtual and probably abstract)
int base::F(int i)
{
int ret;
if (IsParamInRange(i))
ret = DoF(i);
if (IsRetInRange(ret))
return ret;
else
return someError;
}
The idea is to force everyone to use a common "entry point"
to some functionality with derived classes implementing specific
tasks.
Andrew
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
> Hi all,
>
> In which circumstances it is appropriate to declare methods as
non-virtual?
>
> Thanx,
> Adrian.
>
>
Adrian Herscu <bm*****@hotmail.com> wrote: A final method in Java is close to a sealed method in C# - it prevents
further overriding.
And that, as far as I'm concerned, is the principal feature of being
non-virtual.
No - the principal feature of being non-virtual, is that non-virtual methods
are resolved at compile-time (a.k.a. static or early binding), so a call
*always* executes the same implementation.
And that's exactly what a method not being overridable gives you.
In Java, methods can be hidden only by static methods - so, Java has no
concept of non-virtual methods.
No, it has no concept of instance methods hiding other instance
methods, which I view as being separate from having no concept of non-
virtual methods.
Think again. *Only* non-virtual methods can be "hidden".
Not sure where you get that from:
using System;
class Base
{
public virtual void Foo()
{
Console.WriteLine ("Base.Foo");
}
}
class Derived : Base
{
public new void Foo()
{
Console.WriteLine ("Derived.Foo");
}
}
public class Test
{
static void Main()
{
Base b = new Derived();
Derived d = new Derived();
b.Foo();
d.Foo();
}
}
Base.Foo is clearly a virtual method, but as far as I can see
Derived.Foo hides it in exactly the same way as if it were non-virtual.
Take away the keyword "new" and you get a warning:
<quote>
Test.cs(13,17): warning CS0114: 'Derived.Foo()' hides inherited member
'Base.Foo()'. To make the current member override that implementation,
add the override keyword. Otherwise add the new keyword.
</quote>
In my view, they can be sealed to prevent them being virtual any
further.
"...virtual any further" = "...overriden any further"
Yes.
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
It's all a matter of definition, of course, but mine seems to fit in
pretty well with this section from the MSDN on virtual members:
<quote>
The virtual keyword is used to modify a method or property declaration,
in which case the method or the property is called a virtual member.
The implementation of a virtual member can be changed by an overriding
member in a derived class.
When a virtual method is invoked, the run-time type of the object is
checked for an overriding member. The overriding member in the most
derived class is called, which might be the original member, if no
derived class has overridden the member. (For more information on run-
time type and most derived implementation, see 10.5.3 Virtual methods.)
By default, methods are non-virtual. You cannot override a non-virtual
method.
</quote>
OK - but you can still hide it.
Yes, and what's your point? You can hide a non-virtual method in C#.
You can't in Java. That doesn't stop it from being non-virtual.
Here's another one, from the C# language specification:
<quote>
The implementation of a non-virtual method is invariant: The
implementation is the same whether the method is invoked on an instance
of the class in which it is declared or an instance of a derived class.
In contrast, the implementation of a virtual method can be superseded
by derived classes.
</quote>
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
A final method in Java absolutely does *not* satisfy the descriptions of
non-virtual methods above - simply because you cannot hide it as you can in
C#.
Where in that quote does it say that you have to be able to hide a
method in order for it not to be virtual?
Moreover, even a C# "sealed" method which is the most close to a Java
"final" method, can be hidden by further subclasses
Yes, but as I've said, I see hiding as separate notions. You seem to as
well below:
There are two separate notions:
1) Overriding - by overriding, a subclass replaces method pointers in
object's v-table and since all method invokations are made through that
v-table, you will always get the overriding implementation no matter from
which site you call it (either from superclass' site or from subclass'
site) - hence, dynamic binding. Also, that's the reason for naming those
methods "virtual" - because their implementation is not known until
run-time.
2) Hidding - this is a totally different mechanism: method invokations are
resolved during compile-time (static binding); so, there is no v-table to go
through - the call is direct.
Well, unless the new method is also virtual, of course, in which case
you still need a v-table. (If you add an extra class D to your example
which extends D and overrides M2, then do
C x = new D();
C.M2();
then D.M2 will get executed.
In summary: when you call a non-virtual method, you will _always_ get the
same implementation executed; when you call a virtual method, you will *not*
always get the same implementation executed - it depends on the overriding
subclasses.
And what part of that summary (which doesn't mention hiding, note)
doesn't apply to final methods in Java?
//++ run this test ++++++
Why? What do you think it shows? I know what is called... I don't see
why you think that the test shows that Java doesn't have non-virtual
methods.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
100 <10*@100.com> wrote: And that, as far as I'm concerned, is the principal feature of being
non-virtual.
I don't know how is in JAVA, but if you assert here that declaring a method
as *sealed* si the same as declaring non-virtual method you are wrong. Such
a method is still virtulal.
No it's not.
<snip>
A a = new C()
a.f() calls C.f()
Isn't it virtual?
A.f is virtual,but C.f isn't, because you can't override it in a class
that derives from C.
If it wasn't it would call A.f()
Nope. From the C# specification again:
<quote>
The implementation of a virtual member can be changed by an overriding
member in a derived class.
</quote>
Now, can you override f() in a class derived directly from C? No? Then
it's not virtual.
*sealed* modifier force you to stop using overriden until you don't use
*virtual* again and then you can continue override the method.
You can never override the actual sealed method. You can hide it with
another virtual method and then override *that*, but that's not
actually overriding the sealed (non-virtual) method.
BTW the
compiler generates *callvirt* instruction as a evidence of that the method
is indeed *virtual*
That's evidence of A.f() being virtual, not evidence of C.f() being
virtual.
In my view, they can be sealed to prevent them being virtual any
further.
In c# you can keep going with overrideing the method which was sealed.
No you can't.
what
you have to is to declared it as virtual again(to start new virtual
implemetation).
You also have to declare it as "new" and *hide* the previous method.
That's *not* overriding it.
That is posible because when CLR decides, which is most-derived method it
doesn't take into account only the runtime type of the object it kind of
takes into account the type of the variable as well.
The CLR doesn't take that into account; the compiler does.
To be more strict
callvirt is provided with the name of the class from where to start looking
for the most-derived implementation.
Yes, but it will stop when it gets to a sealed method. In other words,
there's no way that you can write a class MyDerivedClass such that
C c = new MyDerivedClass();
c.f();
will call anything other than c.f();
(assuming you don't change C itself).
If you think you can, please demonstrate it.
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
When you put *sealed* modifier for a method you have to put override as well
(other wise it does'n make sence to prohibit overriding of something which
cannot be overrided anyway).
Indeed, but that's irrelevant.
The modifier *override* already means that the method is virtual.
No, it means the method in the class it's deriving from is virtual.
<snip>
If you read further down the same section you will find example of hiding
virtual methods, which is more closely to what happend when you declare a
method as a *sealed*. *sealed* modifier just force you to hide the method if
you want to change the implementation.
That doesn't change the implementation though - it just provides a new
method. It doesn't change the implementation in the same way that
overriding does.
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
If *final* in JAVA means that the method cannod be overriden or hid then it
is different form the non-virtual methods.
It's different from C# due to the fact that you can't hide it, but that
doesn't mean it's non-virtual. You can't hide it just because you can't
hide methods at all in Java. If we were to apply your logic above, we'd
also come to the conclusion that there aren't any virtual methods in
Java either, as they can't be hidden. Do you really believe that every
method in Java is neither virtual nor non-virtual?
Non-virtual methods cannot be overriden - OK. One can hide then, though.
You don't *have* to be able to hide them in order for them to be non-
virtual though! Hiding's just a different concept in the same area.
So my question is: Why C# allows virtual methods to be hidden. Isn't it
error prone.
Not really, because there's a warning message if you try to do it.
I believe that the best is:
1. To have virtual and non-virtual methods.
Which both C# and Java have.
2. Sealing virtual methods has to prevent further overriding and hiding the
methods.
I disagree with this - a warning is all that's required to avoid
hiding. Sealing an otherwise virtual method makes it non-virtual, and
that's all that's required.
And actually I think I know the answer. It is side efect of the way the CLR
resolves wich is the most-derived method. .NET is cross langage platform and
if C# was preventing this using calsses written in other languges (allowing
hiding virtual methods) would put C# programmers to consfusion.
I don't think that was the reason at all. I think it was to prevent
classes from breaking when they're recompiled against newer versions of
libraries they may use. You get a warning if you try to hide a member
(because the member may not have existed before), but you get the same
behaviour, and can remove the warning by explicitly saying that that's
what you wanted to do. Don't forget that this method may itself be part
of a public API which can't easily be changed.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Adrian Herscu <bm*****@hotmail.com> wrote: Java *does* have non-virtual methods (they're called final in Java).
Look at Object.wait() for example.
I think you are wrong. Read the Java Language Specification, para
8.4.3.3: "A method can be declared final to prevent subclasses from overriding or
hiding it. It is a compile-time error to attempt to override or hide a
final method".
A final method in Java is close to a sealed method in C# - it prevents
further overriding.
And that, as far as I'm concerned, is the principal feature of being
non-virtual.
In fact, in C# a non-virtual method which implements an interface method is
actually compiled into a "virtual sealed" method. The only way to tell this
is with ILDASM, since it acts exactly like a non-virtual method.
Eric Gunnerson [MS] <er****@online.microsoft.com> wrote: Anders answers this here:
http://www.artima.com/intv/nonvirtualP.html
Shame Anders has a pretty dodgy section in that article:
<quote>
Anders Hejlsberg: 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.
</quote>
In modern Java VMs (or at least HotSpot), methods are actually treated
as non-virtual until they are overridden, whereupon code which calls
the overridden method is rejitted to make a virtual call. Of course,
this trickery may well have been included only because so many methods
in Java *are* virtual, but I still think it's important to note.
(I agree with the rest of the article though :)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> > Think again. *Only* non-virtual methods can be "hidden".
Not sure where you get that from:
using System;
class Base
{
public virtual void Foo()
{
Console.WriteLine ("Base.Foo");
}
}
class Derived : Base
{
public new void Foo()
{
Console.WriteLine ("Derived.Foo");
}
}
public class Test
{
static void Main()
{
Base b = new Derived();
Derived d = new Derived();
b.Foo();
d.Foo();
}
}
Base.Foo is clearly a virtual method, but as far as I can see
Derived.Foo hides it in exactly the same way as if it were non-virtual.
Take away the keyword "new" and you get a warning:
Base::Foo is clearly declared virtual, but it is not really virtual !
If it were virtual then:
Base b = new Derived();
b.Foo();
would output:
Derived.Foo
That's exactly the semantics of being non-virtual.
And again, "final" in Java is very different from non-virtual - a
non-virtual method can be hidden, but a "final" method cannot be hidden.
Adrian Herscu <bm*****@hotmail.com> wrote: Base.Foo is clearly a virtual method, but as far as I can see
Derived.Foo hides it in exactly the same way as if it were non-virtual.
Take away the keyword "new" and you get a warning:
Base::Foo is clearly declared virtual, but it is not really virtual !
Yes it is. You could create another class which overrides it, and that
would be called if you had:
Base b = new OtherDerived();
b.Foo();
A virtual method doesn't have to actually have *been* overridden to be
virtual.
If it were virtual then:
Base b = new Derived();
b.Foo();
would output:
Derived.Foo
No, that's what would happen if Derived.Foo overrode Base.Foo. It
doesn't, but that's because of Derived.Foo hiding Base.Foo, not because
Base.Foo isn't virtual in the first place. How can the presence or
absence of another method change whether or not a method is virtual?
That's exactly the semantics of being non-virtual.
Nope. The semantics of being non-virtual is that the method can't be
overridden.
And again, "final" in Java is very different from non-virtual - a
non-virtual method can be hidden, but a "final" method cannot be hidden.
But a virtual method can't be hidden either in Java! Whether or not a
method is virtual or not has *nothing* to do with whether or not the
language supports hiding.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi,
Jon Skeet wrote: In modern Java VMs (or at least HotSpot), methods are actually treated
as non-virtual until they are overridden, whereupon code which calls
the overridden method is rejitted to make a virtual call. Of course,
this trickery may well have been included only because so many methods
in Java *are* virtual, but I still think it's important to note.
So if you need that extra performance (but I can't think of a good reason
why you would), you have to try and guess what the Java jitter is going to
do?
Interesting that he says virtual and override say different things.. I
hadn't thought of it that way before.
-- Pete
Pete <pv*****@gawab.com> wrote: Jon Skeet wrote: In modern Java VMs (or at least HotSpot), methods are actually treated
as non-virtual until they are overridden, whereupon code which calls
the overridden method is rejitted to make a virtual call. Of course,
this trickery may well have been included only because so many methods
in Java *are* virtual, but I still think it's important to note.
So if you need that extra performance (but I can't think of a good reason
why you would), you have to try and guess what the Java jitter is going to
do?
Not really - it's not like you have to change your code to take
advantage of it. Knowing what the JIT is capable of (and its
limitations) is likely to help though - and that's not unique to Java
by any means. It's a bit of a chicken-and-egg situation. The more you
know about how any one implementation of the CLR or Java VM works, the
better you're likely to be able to write code for that particular
archiecture - but what's good for one might be awful for another. For
instance, with one garbage collector and heap allocator, object pooling
could be a really good idea; with another, it might be something to
avoid.
Interesting that he says virtual and override say different things.. I
hadn't thought of it that way before.
I'm not exactly sure about which bit you mean, but yes - it's generally
good stuff.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
1.
A virtual method has to execute the same implementation, no matter through
which interface it was invoked.
And in your example, it does matter.
IMHO, the "virtual" term is not about declarations, it's about behavior. So,
if a method doesn't behave as "virtual", then it is not virtual.
At the end, (in C#) it depends on the direct subclass if a declared virtual
method is actually virtual.
And this is a fundamental difference between C# and the others (C++ and
Java):
In C++, a declared virtual method will always be overridden by a subclass
owning a method with the same signature.
In Java all non-finalized instance methods are virtual.
2.
Consider this:
using System;
class Base {
static private void DoBaseFoo() { Console.WriteLine("Did Base Foo"); }
public void Foo() { DoBaseFoo(); }
}
class Derived : Base {
static private void DoDerivedFoo() { Console.WriteLine("Did Derived
Foo"); }
new public void Foo() { DoDerivedFoo(); }
}
class TestNonVirtual {
static public void Main() {
Object d = new Derived();
((Base)d).Foo(); // This will execute DoBaseFoo()
((Derived)d).Foo(); // and this will execute DoDerivedFoo().
/*
That is because Base::Foo is non-virtual not only by
declaration,
but also by behavior.
*/
}
}
Can you build such a thing in Java? If you can, then Java supports
non-virtual methods.
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Adrian Herscu <bm*****@hotmail.com> wrote: Base.Foo is clearly a virtual method, but as far as I can see
Derived.Foo hides it in exactly the same way as if it were
non-virtual. Take away the keyword "new" and you get a warning:
Base::Foo is clearly declared virtual, but it is not really virtual !
Yes it is. You could create another class which overrides it, and that
would be called if you had:
Base b = new OtherDerived();
b.Foo();
A virtual method doesn't have to actually have *been* overridden to be
virtual.
If it were virtual then:
Base b = new Derived();
b.Foo();
would output:
Derived.Foo
No, that's what would happen if Derived.Foo overrode Base.Foo. It
doesn't, but that's because of Derived.Foo hiding Base.Foo, not because
Base.Foo isn't virtual in the first place. How can the presence or
absence of another method change whether or not a method is virtual?
That's exactly the semantics of being non-virtual.
Nope. The semantics of being non-virtual is that the method can't be
overridden.
And again, "final" in Java is very different from non-virtual - a
non-virtual method can be hidden, but a "final" method cannot be hidden.
But a virtual method can't be hidden either in Java! Whether or not a
method is virtual or not has *nothing* to do with whether or not the
language supports hiding.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Sounds like programmers will develop dependence on some particular
implementation.
As a driver, I don't care if my car engine has a central-point injection or
multi-point injection system - I will use it the same way!
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Pete <pv*****@gawab.com> wrote: Jon Skeet wrote: In modern Java VMs (or at least HotSpot), methods are actually treated
as non-virtual until they are overridden, whereupon code which calls
the overridden method is rejitted to make a virtual call. Of course,
this trickery may well have been included only because so many methods
in Java *are* virtual, but I still think it's important to note.
So if you need that extra performance (but I can't think of a good
reason why you would), you have to try and guess what the Java jitter is going
to do?
Not really - it's not like you have to change your code to take
advantage of it. Knowing what the JIT is capable of (and its
limitations) is likely to help though - and that's not unique to Java
by any means. It's a bit of a chicken-and-egg situation. The more you
know about how any one implementation of the CLR or Java VM works, the
better you're likely to be able to write code for that particular
archiecture - but what's good for one might be awful for another. For
instance, with one garbage collector and heap allocator, object pooling
could be a really good idea; with another, it might be something to
avoid.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Adrian Herscu <bm*****@hotmail.com> wrote: 1.
A virtual method has to execute the same implementation, no matter through
which interface it was invoked.
And in your example, it does matter.
Only because the virtual method doesn't enter into it - the hiding
method means that it's called instead of a virtual call being made.
That has nothing to do with whether or not the base method is virtual.
IMHO, the "virtual" term is not about declarations, it's about behavior. So,
if a method doesn't behave as "virtual", then it is not virtual.
I disagree entirely. A method doesn't just "become" virtual due to
having been overridden elsewhere. A method is virtual if it *can* be
overridden. That's all there is to it. Note that you're also
disagreeing with the C# language specification here, which says:
<quote>
When an instance method declaration includes a virtual modifier, that
method is said to be a virtual method.
</quote>
Do you at least agree, given that your above, that your idea of a
method being virtual is not the same as the C# language specification's
idea?
At the end, (in C#) it depends on the direct subclass if a declared virtual
method is actually virtual.
No it doesn't - because otherwise you've got the situation where it's
half-virtual and half-not-virtual, if it's overridden in one class and
hidden in another.
And this is a fundamental difference between C# and the others (C++ and
Java):
In C++, a declared virtual method will always be overridden by a subclass
owning a method with the same signature.
In Java all non-finalized instance methods are virtual.
Which means that finalized instance methods are non-virtual, as I said
before and which you disagreed with.
2.
Consider this:
using System;
class Base {
static private void DoBaseFoo() { Console.WriteLine("Did Base Foo"); }
public void Foo() { DoBaseFoo(); }
}
class Derived : Base {
static private void DoDerivedFoo() { Console.WriteLine("Did Derived
Foo"); }
new public void Foo() { DoDerivedFoo(); }
}
class TestNonVirtual {
static public void Main() {
Object d = new Derived();
((Base)d).Foo(); // This will execute DoBaseFoo()
((Derived)d).Foo(); // and this will execute DoDerivedFoo().
/*
That is because Base::Foo is non-virtual not only by
declaration,
but also by behavior.
*/
}
}
Can you build such a thing in Java? If you can, then Java supports
non-virtual methods.
No, but I don't *need* to for Java to support non-virtual methods. I
repeat, hiding is *not* a necessity for non-virtual methods to be
supported.
As you said before:
"In Java all non-finalized instance methods are virtual."
So what are finalized instance methods? Are they virtual or are they
not, according to your understanding?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I agree on that there are multiple perspectives.
About specs in general - they are not holly scripts (yet).
Anyway, the original question was: "In which circumstances it is appropriate
to declare methods as non-virtual?".
I read Anders' interview, and the answer to the above question is burried
somewere in.
Thank you all,
Adrian.
Non-virtual methods cannot be overriden - OK. One can hide then, though.
You don't *have* to be able to hide them in order for them to be non-
virtual though! Hiding's just a different concept in the same area.
So my question is: Why C# allows virtual methods to be hidden. Isn't it
error prone.
Not really, because there's a warning message if you try to do it.
Imagine tha you' ve got a class framework from third party
tha class is something like
class Foo: FooBase
{
new public virtual string ToString()
{
....
}
}
class Bar: Foo
{
public override string ToString()
{
.....
}
}
You desided to inherit from Bar
class MyBar: Bar
{
public override string ToString()
{
}
}
Then
object obj = new MyBar()
Console.WriteLine(obj); //result is FooBase's base ToString();
How hard is to find what is going on here?
In my class I override a method which is declared as a virtual in the Object
class and is overriden in my base class. How could I know that it is has
been hidden in some of my base's base classes.
Before you start arguing that noone will hide ToString() I'll tell you that
is true because noone will hide any virtual method. Otherwise I don't want
to be progammer using one's framework. or class library.
I believe that the best is:
1. To have virtual and non-virtual methods.
Which both C# and Java have.
2. Sealing virtual methods has to prevent further overriding and hiding
the methods.
I disagree with this - a warning is all that's required to avoid
hiding. Sealing an otherwise virtual method makes it non-virtual, and
that's all that's required.
Yes, the warning will warn me and I'll use the *new* keyword to make the
compiler happy. What about the others that will inherit my class and will
struggle to find why their code doesn't work as expected with virtual
methods.
And actually I think I know the answer. It is side efect of the way the
CLR resolves wich is the most-derived method. .NET is cross langage platform
and if C# was preventing this using calsses written in other languges
(allowing hiding virtual methods) would put C# programmers to consfusion.
I don't think that was the reason at all. I think it was to prevent
classes from breaking when they're recompiled against newer versions of
libraries they may use. You get a warning if you try to hide a member
(because the member may not have existed before), but you get the same
behaviour, and can remove the warning by explicitly saying that that's
what you wanted to do. Don't forget that this method may itself be part
of a public API which can't easily be changed.
Frankly I didn't get that.
Let imagine for a sec that there wasn't *publi virtual string ToString()*
method in Object class. I've needed it so I've added *public string
ToString()* method in my class.
You are trying to tell me that if later they add *public virtual string
ToString()* method in the Object class I'll put a new keyword infornt of my
ToString implemetation.
Rather I'll put *override* for that ToString method of mine. And I don't see
any case where one will put *new*. I don't see how my class introducing new
implementation of ToString will work correctly with the rest of the classes
in the framework.
Brgds
100
"Adrian Herscu" <bm*****@hotmail.com> wrote in message
news:Ov**************@TK2MSFTNGP10.phx.gbl... Sounds like programmers will develop dependence on some particular
implementation.
As a driver, I don't care if my car engine has a central-point injection
or multi-point injection system - I will use it the same way!
In a normal case that is true. But as programmers we are often pushing the
limits. We sometimes need to know the internals to get the performance we
need even if that means the application is less portable.
To give you a car example:
I drive a Subaru WRX, it's all wheel drive with a fairly sophisticated
system for distributing engine torque to the wheels. No normal person needs
to know this to drive the car. In fact you don't even need to know it's all
wheel drive. However I depend on this particular implementation since my
normal application (going up my driveway in the winter) is beyond what a
typical two wheel drive implementation can do.
100 <10*@100.com> wrote: Non-virtual methods cannot be overriden - OK. One can hide then, though.
You don't *have* to be able to hide them in order for them to be non-
virtual though! Hiding's just a different concept in the same area.
So my question is: Why C# allows virtual methods to be hidden. Isn't it
error prone.
Not really, because there's a warning message if you try to do it.
Imagine tha you' ve got a class framework from third party
tha class is something like
<snip>
Then
object obj = new MyBar()
Console.WriteLine(obj); //result is FooBase's base ToString();
How hard is to find what is going on here?
Well, it's not hard when you've seen it happen, of course, but I take
your point.
In my class I override a method which is declared as a virtual in the Object
class and is overriden in my base class. How could I know that it is has
been hidden in some of my base's base classes.
As far ass I know, you can't - and yes, that's a problem.
I disagree with this - a warning is all that's required to avoid
hiding. Sealing an otherwise virtual method makes it non-virtual, and
that's all that's required.
Yes, the warning will warn me and I'll use the *new* keyword to make the
compiler happy. What about the others that will inherit my class and will
struggle to find why their code doesn't work as expected with virtual
methods.
One thing to do of course is document everything. Don't forget that
most methods *shouldn't* be virtual. I think it *would* be rare to hide
one virtual method with another virtual method. All three of "methodn
in base class is virtual", "method in derived class is virtual",
"method in derived class hides method in base class" should be rare.
And then, yes, you've got a problem.
I don't think that was the reason at all. I think it was to prevent
classes from breaking when they're recompiled against newer versions of
libraries they may use. You get a warning if you try to hide a member
(because the member may not have existed before), but you get the same
behaviour, and can remove the warning by explicitly saying that that's
what you wanted to do. Don't forget that this method may itself be part
of a public API which can't easily be changed.
Frankly I didn't get that.
Let imagine for a sec that there wasn't *publi virtual string ToString()*
method in Object class. I've needed it so I've added *public string
ToString()* method in my class.
You are trying to tell me that if later they add *public virtual string
ToString()* method in the Object class I'll put a new keyword infornt of my
ToString implemetation.
If you want behaviour to stay the same, you should, yes.
Rather I'll put *override* for that ToString method of mine. And I don't see
any case where one will put *new*.
In that case a lot of your code may well break. Developers who only
know about the base class may well call the method, requiring very
different semantics from those that your class provides. You may well
have documented that your method should only be called in certain ways,
for instance - and suddenly it's being called in other ways due to
overriding the base class method.
I don't see how my class introducing new
implementation of ToString will work correctly with the rest of the classes
in the framework.
But that's the point - the things which knew about your ToString method
before will still call it, and the things which didn't won't - which is
usually what you want.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: lothar |
last post by:
re:
4.2.1 Regular Expression Syntax
http://docs.python.org/lib/re-syntax.html
*?, +?, ??
Adding "?" after the qualifier makes it perform the match in non-greedy or
minimal fashion; as few...
|
by: klaus triendl |
last post by:
hi,
recently i discovered a memory leak in our code; after some investigation i
could reduce it to the following problem:
return objects of functions are handled as temporary objects, hence...
|
by: Steve - DND |
last post by:
We're currently doing some tests to determine the performance of static vs
non-static functions, and we're coming up with some odd(in our opinion)
results. We used a very simple setup. One class...
|
by: Bern McCarty |
last post by:
Is it at all possible to leverage mixed-mode assemblies from AppDomains
other than the default AppDomain? Is there any means at all of doing this?
Mixed-mode is incredibly convenient, but if I...
|
by: Patrick Kowalzick |
last post by:
Dear all,
I have an existing piece of code with a struct with some PODs.
struct A
{
int x;
int y;
};
|
by: Ian825 |
last post by:
I need help writing a function for a program that is based upon the various operations of a matrix and I keep getting a "non-aggregate type" error. My guess is that I need to dereference my...
|
by: amitvps |
last post by:
Secure Socket Layer is very important and useful for any web application but it brings some problems too with itself. Handling navigation between secure and non-secure pages is one of the cumbersome...
|
by: =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= |
last post by:
PEP 1 specifies that PEP authors need to collect feedback from the
community. As the author of PEP 3131, I'd like to encourage comments
to the PEP included below, either here (comp.lang.python), or...
|
by: asm23 |
last post by:
Hi,I need some help to clarify the warning "initial value of reference
to non-const must be an lvalue".
I'm searching in this groups to find someone has the same situation like
me. I found in...
|
by: puzzlecracker |
last post by:
is it even possible or/and there is a better alternative to accept
input in a nonblocking manner?
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
