new vs override - a practical example

  • Thread starter Thread starter bonk
  • Start date Start date
B

bonk

Did anyone EVER come across the need to use "new" in a method
declaration (breaking with inheritance / versioning)? Allthough I know
what it does and how it is used I really have a hard time to make up a
usefull real life scenario for it. Maybe you can give a practical
example from a real life?
 
Let's say you are inheriting from a class you did not write. It has a Clear
method that is not declared as allowing it to be overridden. So there is no
way for you to override it. You would have to write a method called Clear2
or something.
So, instead you use 'new' to just have your own Clear method that can be
called on that object. That also means you can't call the original version
without casting to the base class.
 
Marina said:
Let's say you are inheriting from a class you did not write. It has a Clear
method that is not declared as allowing it to be overridden. So there is no
way for you to override it. You would have to write a method called Clear2
or something.
So, instead you use 'new' to just have your own Clear method that can be
called on that object. That also means you can't call the original version
without casting to the base class.
Click to expand...
Sorry, that was not quite what I was looking for, maybe I should be more
specific. It is clear to me that I have to use "new" to redefine a
mehtod that doesn't have virtual in its declaration. I was more looking
for a practical example for when I would prefer "new" INSTEAD of
"override" to hide the VIRTUAL mehtod of the baseclass I derived from:

class A
{
public virtual void DoIt(){}
}
class B : A
{
public /*override (or) new (with or without) virtual*/ void DoIt() {}
}
class C : B
{
public /*override (or) new*/ void DoIt()
}
 
bonk said:
Sorry, that was not quite what I was looking for, maybe I should be more
specific. It is clear to me that I have to use "new" to redefine a
mehtod that doesn't have virtual in its declaration. I was more looking
for a practical example for when I would prefer "new" INSTEAD of
"override" to hide the VIRTUAL mehtod of the baseclass I derived from:

class A
{
public virtual void DoIt(){}
}
class B : A
{
public /*override (or) new (with or without) virtual*/ void DoIt() {}
}
class C : B
{
public /*override (or) new*/ void DoIt()
}
Click to expand...
I use it from time to time to make my coode more readable:

class AImp{}
class BImp: AImp{}

class A
{
protected AImp Pimpl{ get; }
}

b uses a BImp
class B : A
{
private new BImp Pimpl{ get; }
}

so inside of B intead of writing ((BImp)Pimpl).DoIt(), I can use
Pimpl.DoIt();

HTH,
Andy
 
Ok. You are writing a system using martin.dll which exposes a useful class
called Employee ...

public class Employee {

decimal salary;

...

public decimal Salary {get{...} set{...}}
...

public decimal GetPayAmount() {
return this.salary / 12;
}

}

(well not that useful but ...)

Your company wants to start paying weekly. You do not have the source for
martin.dll, so how do you change the GetPayAmount() value?

public class Employee2 : Employee {

public new decimal GetPayAmount() {
return this.Salary/52;
}

}

Any clearer?
 
bonk said:
Did anyone EVER come across the need to use "new" in a method
declaration (breaking with inheritance / versioning)? Allthough I
know what it does and how it is used I really have a hard time to
make up a usefull real life scenario for it. Maybe you can give a
practical example from a real life?
Click to expand...

Sure, any static method you want to give different behavior in a
derived class.

Or as others said: you want to specify a different method in a derived
class and the method isn't virtual. A good example why you need that is
in the silly collection classes in .NET, they all don't have a virtual
Add() method for example. If you want to perform additional code in the
Add method, you can only do that if you use 'new'.

FB

--
 
I've used it to add accessors to a property, when a base class has a
property that's read-only, but I want it to be read-write in a derived
class. Unfortunately I have to create an intermediate class to do it:

// read-only Height is fine for most classes derived from B...
abstract class B {
abstract int Height { get; }
}

// but for D it has to be read-write
abstract class Bhack : B {
// implement B.Height by calling into the derived class
override int Height { get { return HackGetHeight(); } }
protected abstract int HackGetHeight();
}

class D : Bhack {
// answer the call from Bhack.Height
protected sealed override HackGetHeight() { return this.Height; }
// and replace the old property with a new one
new int Height { get { ... } set { ... } }
}

Jesse
 
So, instead you use 'new' to just have your own Clear method that can be
called on that object. That also means you can't call the original version
without casting to the base class.
Click to expand...

This is not true.

class Foo
{
public int f() { return 0; }
}
class Bar: Foo
{
public new int f() { return 1; }
}
class Test
{
public static void Main()
{
Bar bar = new Bar();
System.Console.WriteLine("bar.f()={0}", bar.f());
Foo foo = bar;
System.Console.WriteLine("foo.f()={0}", foo.f());
}
}


Many of the replies in the threads tries to tell you to use "new" to do
override without virtual. The above is why that doesn't work.
 
I've used it to add accessors to a property, when a base class has a
property that's read-only, but I want it to be read-write in a derived
class. Unfortunately I have to create an intermediate class to do it:
Click to expand...

How about:

class Prop
{
public int P { get { return 1; } }
}
class Prop2: Prop
{
public Prop2() { p = base.P; }
protected int p;
public new int P { get { return p; } set { p = value; } }
}

class Test
{
public static void Main()
{
Prop2 p2 = new Prop2();
Prop p = p2;
System.Console.WriteLine("p2.P=={0}", p2.P);
p2.P = 5;
System.Console.WriteLine("p2.P=={0}", p2.P);
// p.P = 5; // <-- will error
}
}
 
Helge said:
How about:
Click to expand...

Ups, sorry, read that wrong:

abstract class Prop
{
public abstract int P { get; }
}
class Prop2: Prop
{
public int p;
public override int P {get { return p; } }
}

class Test
{
public static void Main()
{
Prop2 p2 = new Prop2();
Prop p = p2;
System.Console.WriteLine("p2.P=={0}", p2.P);
System.Console.WriteLine("p.P=={0}", p.P);
p2.p = 5;
System.Console.WriteLine("p2.P=={0}", p2.P);
System.Console.WriteLine("p.P=={0}", p.P);
}
}
 
Making that field public doesn't seem like a very good design. For
example, I want to make sure that Height is never negative, and I can't
guarantee that if the field is public.

The other alternative would be to use a set method instead of an
accessor:

abstract class B {
public abstract int Height { get; }
}

class D : B {
public override int Height { get { ... } }
public void SetHeight(int value) { ... }
}

But that's ugly.. properties are supposed to replace set and get
methods. This is C#, not Java. Making an intermediate class and
reintroducing the property with 'new' isn't beautiful either, but it
does what I want, and it'll work correctly if anyone wants to set the
property with reflection.

I don't know why I can't just add the accessor in the derived class,
honestly. It doesn't seem like it'd break anything.

Jesse
 
Marina was correct.

Of course it won't work *exactly* like a virtual method. Without
virtual, all you have is static binding, which means you'll call
Foo.f() when you're calling through a Foo reference and Bar.f() when
you're calling through a Bar reference.

But that may be good enough if you have control over all the code
that's using the class. That is, you can create a Bar object, and its
f() method will do what you want as long as you never assign it to a
Foo variable, never pass it to a method that expects a Foo, and none of
the inherited methods from Foo call f().

Jesse
 
Marina was correct.
Click to expand...

The statement was: "That also means you can't call the original version
without casting to the base class.". This statement is false.

Of course the only proper solution is to declare f() virtual in Foo.
But that may be good enough if you have control over all the code
that's using the class. That is, you can create a Bar object, and its
f() method will do what you want as long as you never assign it to a
Foo variable, never pass it to a method that expects a Foo, and none of
the inherited methods from Foo call f().
Click to expand...

It's *very* hard to be sure you have control over all the code using the
class, for one thing, the type-system won't help you at all, neither
staticly or dynamicly. Since you inherit from Foo, and need to override
f() in Foo it's rather likely that some other code is going to use your
Bar instance as a Foo.

Using "new" to override a method that should have been virtual is a hack
that leads to unreadable code. If you do have complete control over the
code that uses Bar it can be replaced by, either naming the f() in Bar
something else -- proper to it's usage in Bar, or:

class Bar {
public void HACK_SINCE_f_IS_NOT_VIRTUAL() { /* impl. of f() */ }
public new f() {
throw new NotSupported(
string.format("call HACK_SINCE_f_IS_NOT_VIRTUAL instead"));
}

Which clearly shows that a hack is in progress.
 
Making that field public doesn't seem like a very good design. For
example, I want to make sure that Height is never negative, and I can't
guarantee that if the field is public.
Click to expand...

There is always:

class Prop2: Prop
{
public int p { get { ...; } set { ...; } }
public override int P { get { return p; } }
}

:)
But that's ugly.. properties are supposed to replace set and get
methods. This is C#, not Java. Making an intermediate class and
reintroducing the property with 'new' isn't beautiful either, but it
does what I want, and it'll work correctly if anyone wants to set the
property with reflection.
Click to expand...

Do you expect people to set it via reflection? if not, I wouldn't worry
about it. A a side note, the solution above also works via reflection.
I don't know why I can't just add the accessor in the derived class,
honestly. It doesn't seem like it'd break anything.
Click to expand...

It would be perfectly sound from a typing-perspective, the problem is
that a property is treated as *one* function, not two - by the
typesystem. This is also why you cannot have get public and set
protected. I seem to vaguely recall some comments about this being
mended in C#2,... anyone?

You can actually use explicit interface implementation to side-step this
problem very nicely:

interface B {
int Height { get; }
}

class D : B {
int B.Height { get { return Height; } }
int Height { get { ...; } set { ...; } }
}
 
It's false? If you have a base class A, and a derived class B. Class A has
a non-virtual method Foo, and B has its own version with new.

Now you have

B test = new B();

How do you call A's version of Foo without casting to an A first? If you
call 'test.Foo()', you will call B's version. Not A's.

Also, no one was saying that using 'new' is the right way to do it. The
original question is, why would you want to. The only answer I can think of
is that you don't want to do it unless you have no other option because you
have no control over the source code of the ancestor class.
 
Did anyone EVER come across the need to use "new" in a method
declaration (breaking with inheritance / versioning)? Allthough I know
what it does and how it is used I really have a hard time to make up a
usefull real life scenario for it. Maybe you can give a practical
example from a real life?
Click to expand...

Here's one that I need everytime I create a descendant of EventArgs.

public class SomethingHappenedEventArgs : EventArgs
{
new public static readonly SomethingHappenedEventArgs Empty = new SomethingHappenedEventArgs
();

public SomethingHappenedEventArgs()
{}

...
}

Reason being: Say you have a method that takes a MyEventArgs as a parameter
and you just want to pass an emtpy argument list. You can't pass EventArgs.Empty.

public void OnSomethingHappened(SomethingHappenedEventArgs args)
{
...
}

I suppose you could call it like OnSomethingHappened(new SomethingHappenedEventArgs())
or even OnSomethingHappened(null) though ;)

Providing the new Empty implementation just feels cleaner to me
 
Sorry for the nonstandard quoting, Google Groups doesn't have a quote
button...

"It would be perfectly sound from a typing-perspective, the problem is
that a property is treated as *one* function, not two - by the
typesystem. This is also why you cannot have get public and set
protected. I seem to vaguely recall some comments about this being
mended in C#2,... anyone?"

I don't think this is accurate. A property is just a bit of metadata
that describes one or two functions, and as you mentioned, C# 2.0 lets
you specify different accessibility on the set and get accessors. You
could do the same with Managed C++ even in .NET 1.1, IIRC.

In fact, you can add a set accessor to an inherited read-only property
in C++/CLI and ILASM. (See the C++ code below, which compiles with
/clr:safe and passes peverify.) This is a limitation of C#, not .NET.

"You can actually use explicit interface implementation to side-step
this
problem very nicely"

Unfortunately that only works for interfaces, not base classes.

Jesse

===== C++ CODE =====

// propAccTestCPP.cpp : main project file.

#include "stdafx.h"

using namespace System;

ref class Base abstract
{
public:
property int Prop
{
virtual int get() abstract;
}
};

ref class Derived : public Base
{
private:
int x;

public:
property int Prop
{
virtual int get() override
{
return x;
}
virtual void set(int value)
{
x = value;
}
}
};

int main(array<System::String ^> ^args)
{
Derived^ d = gcnew Derived();
d->Prop = 123;
System::Console::WriteLine(d->Prop);
return 0;
}
 
Marina said:
B test = new B();

How do you call A's version of Foo without casting to an A first? If you
call 'test.Foo()', you will call B's version. Not A's.
Click to expand...

A testa = test;
testa.Foo(); // invokes A.Foo on test

This can easily happen without the programmer noticing, for example if a
function returns the value, or assigns it to a member. The type-system
won't warn you -- the program will compile, run, and behave contrary to
the usual behaviour.
Also, no one was saying that using 'new' is the right way to do it. The
original question is, why would you want to. The only answer I can think of
is that you don't want to do it unless you have no other option because you
have no control over the source code of the ancestor class.
Click to expand...

What I'm saying is, that even in this case, it's not too good, and you
would probably do better by using another name for the member.

new doesn't make the member virtual.

new overloads the semantics of a member after the static type of it's
object. This is the opposite of the normal semantics of members, which
are either sigularly defined, or overloaded after the dynamic-type of
it's object.
 
Sorry for the nonstandard quoting, Google Groups doesn't have a quote
button...
Click to expand...

no problem.
"It would be perfectly sound from a typing-perspective, the problem is
that a property is treated as *one* function, not two - by the
typesystem. This is also why you cannot have get public and set
protected. I seem to vaguely recall some comments about this being
mended in C#2,... anyone?"

I don't think this is accurate. A property is just a bit of metadata
that describes one or two functions, and as you mentioned, C# 2.0 lets
you specify different accessibility on the set and get accessors. You
could do the same with Managed C++ even in .NET 1.1, IIRC.
Click to expand...

I should have said: "by the C# typesystem", I didn't notice the
ambiguity -- possibly because I continued "...mended in C#2...".
In fact, you can add a set accessor to an inherited read-only property
in C++/CLI and ILASM. (See the C++ code below, which compiles with
/clr:safe and passes peverify.) This is a limitation of C#, not .NET.
Click to expand...

I think we agree on that.
"You can actually use explicit interface implementation to side-step
this
problem very nicely"

Unfortunately that only works for interfaces, not base classes.
Click to expand...

Another nail in the coffin of abstract classes, a small one though.
 
Back
Top