On Friday, 4 September 2015 at 11:44:44 UTC, BBasile wrote:
What's so different with C# 'new' that not to call 'super' in a
D overriden method ? (even if C# has itself 'base' instead of
'super')
C#
---
public class BaseC
{
public int x;
public void Invoke() { }
}
public class DerivedC : BaseC
{
new public void Invoke() { }
}
---
D
---
class BaseC
{
int x;
void Invoke() { }
}
class DerivedC : BaseC
{
override void Invoke() { /*super.Invoke() not called*/ }
}
---
apart from a compiler warning
(https://msdn.microsoft.com/en-us/library/ms173153.aspx=
It is just a warning, because it's ultimately there to warn you
of something you may not have noticed.
For example:
abstract class BaseA {
abstract void foo();
}
class A : BaseA {
override void foo() { }
virtual void foobar() { }
}
All is well.
But then BaseA (which may be in a different library), suddenly
becomes:
abstract class BaseA {
abstract void foo();
virtual void foobar() { dostuff(); }
}
Now you have A, which has foobar, but isn't actually related to
BaseA.foobar. You probably didn't mean to override foobar, but
it's still confusing for anything expecting BaseA.foobar to be
related to A.foobar. You might not even know BaseA.foobar was
added if it was part of a different library. Or, even worse:
class B : A {
override void foobar() {
dootherstuff();
}
}
It definitely gets a bit odd, and new is there just to prevent
confusion / clarify intentions, as well as let you know when a
new method is added with the same name. The whole situation is
messy, like what happens when A.foobar is removed and you
suddenly start overriding BaseA.foobar instead. Or what if you
were intending to override BaseA.foobar, but now you're suddenly
overriding A.foobar once A adds the method? I'd actually prefer
to specifically have to write 'override void A.foobar()' if
A.foobar is marked as 'new' for this reason and make it an error
to not include new or override when dealing with the same name. D
could probably benefit from this approach as well, for the same
reasons.
