www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is Override Still Mandatory?

reply "Vijay Nayar" <madric gmail.com> writes:
I was under the impression that the attribute "override" was 
mandatory when replacing a virtual function in a base class.  
However, code that leaves this out has no errors using dmd v2.060.

import std.stdio;

class A {
   this() {
     show();
   }
   void show() {
     writeln("A");
   }
}

class B : A {
   this() {
     super();
   }

   // No override and no compiler errors?
   void show() {
     writeln("B");
   }
}

void main() {
   auto b = new B();
   // This prints "B".
}

Also, is there a way to make class A call it's own version of 
show()?

  - Vijay
Nov 11 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 12, 2012 03:58:17 Vijay Nayar wrote:
 I was under the impression that the attribute "override" was
 mandatory when replacing a virtual function in a base class.
 However, code that leaves this out has no errors using dmd v2.060.

It's mandatory if you compile with -w. Eventually, it will be mandatory all the time. It's just that it's being phased in via -w rather than requiring it immediately. That way, people have time to fix their code to use it before it's required. Unfortunately though, a lot of people fail to compile with either -w or -wi, so they're happily writing _new_ code which will break once override is always required, which means that phasing like this doesn't necessarily actually fix the problem. - Jonathan M Davis
Nov 11 2012
prev sibling next sibling parent "Vijay Nayar" <madric gmail.com> writes:
Thanks for the info!  I'll start using -w for all my projects.
  - Vijay

On Monday, 12 November 2012 at 03:08:35 UTC, Jonathan M Davis 
wrote:
 On Monday, November 12, 2012 03:58:17 Vijay Nayar wrote:
 I was under the impression that the attribute "override" was
 mandatory when replacing a virtual function in a base class.
 However, code that leaves this out has no errors using dmd 
 v2.060.

It's mandatory if you compile with -w. Eventually, it will be mandatory all the time. It's just that it's being phased in via -w rather than requiring it immediately. That way, people have time to fix their code to use it before it's required. Unfortunately though, a lot of people fail to compile with either -w or -wi, so they're happily writing _new_ code which will break once override is always required, which means that phasing like this doesn't necessarily actually fix the problem. - Jonathan M Davis

Nov 11 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Unfortunately though, a lot of people fail to compile with 
 either -w
 or -wi, so they're happily writing _new_ code which will break 
 once override
 is always required, which means that phasing like this doesn't 
 necessarily
 actually fix the problem.

I agree. Generally I think warnings should be active on default and disabled on request with a switch :-) Bye, bearophile
Nov 11 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Monday, 12 November 2012 at 03:08:35 UTC, Jonathan M Davis 
wrote:
 On Monday, November 12, 2012 03:58:17 Vijay Nayar wrote:
 I was under the impression that the attribute "override" was
 mandatory when replacing a virtual function in a base class.
 However, code that leaves this out has no errors using dmd 
 v2.060.

It's mandatory if you compile with -w. Eventually, it will be mandatory all the time. It's just that it's being phased in via -w rather than requiring it immediately. That way, people have time to fix their code to use it before it's required. Unfortunately though, a lot of people fail to compile with either -w or -wi, so they're happily writing _new_ code which will break once override is always required, which means that phasing like this doesn't necessarily actually fix the problem. - Jonathan M Davis

I was about to ask this same question today! Thanks for the answer. --rt
Nov 13 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Monday, 12 November 2012 at 03:29:09 UTC, bearophile wrote:
 I agree. Generally I think warnings should be active on default 
 and disabled on request with a switch :-)

 Bye,
 bearophile

Agreed! Fortunately I have not written all that much broken code yet. I recall a lot of discussion about how "depreciated" should work, and it's clear what we have now is next to useless, so I hope the suggestion that was made to improve depreciated with warnings and so forth, is implemented. --rt
Nov 13 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Rob T:

 so I hope the suggestion that was made to improve depreciated 
 with warnings and so forth, is implemented.

"Deprecated features as warnings" is in the D front since about 7 hours: https://github.com/D-Programming-Language/dmd/commit/5881617a34adc172b830314c17da21d5c834ffd0 Bye, bearophile
Nov 13 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 02:33:47 UTC, bearophile wrote:
 Rob T:

 so I hope the suggestion that was made to improve depreciated 
 with warnings and so forth, is implemented.

"Deprecated features as warnings" is in the D front since about 7 hours: https://github.com/D-Programming-Language/dmd/commit/5881617a34adc172b830314c17da21d5c834ffd0 Bye, bearophile

That's good news. If I were to use the latest pre-release version of dmd that was relatively safe, how will I find it, or is it OK to use the master branch? --rt
Nov 13 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 02:33:47 UTC, bearophile wrote:
 Rob T:

 so I hope the suggestion that was made to improve depreciated 
 with warnings and so forth, is implemented.

"Deprecated features as warnings" is in the D front since about 7 hours: https://github.com/D-Programming-Language/dmd/commit/5881617a34adc172b830314c17da21d5c834ffd0 Bye, bearophile

That's good news. If I were to use the latest pre-release version of dmd that was relatively safe, how will I find it, or is it OK to use the master branch? --rt
Nov 13 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 14, 2012 07:59:06 Rob T wrote:
 That's good news. If I were to use the latest pre-release version
 of dmd that was relatively safe, how will I find it, or is it OK
 to use the master branch?

The master branch _is_ the pre-release version. dmd, druntime, and Phobos do not really use proper branches at this point (and even if they did, I wouldn't expect there to be a branch separate from master prior to a beta). It should be reasonably safe to use, but there's no telling how it will affect your code differently from the last release. At minimum there are several known regressions (which will be fixed prior to the next release), and there may be others. Personally, I use master all the time, but I'm one of the Phobos developers. It's fine if you use master (it could help us find regressions if nothing else), but I wouldn't really advise using it just to be able to use the -di flag. Also, some of us are hoping that the change to deprecated will be reverted in favor of making it so that warnings will be the default for using deprecated symbols rather than having error be the default. Having -di is nice, but it really doesn't fix much. The main problem (at least from the library writer's point of view) is that deprecating anything instantly breaks the code of anyone using that the now deprecated symbol. -di makes it so that a programmer can protect themselves from that, but it still shackles the library writer such that they can't deprecate anything if they don't ever want to break anyone's code without giving more warning that a note in the changelog or documentation. - Jonathan M Davis
Nov 14 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 08:04:55 UTC, Jonathan M Davis 
wrote:
  but I'm one of
 the Phobos
 developers. It's fine if you use master (it could help us find 
 regressions if
 nothing else), but I wouldn't really advise using it just to be 
 able to use
 the -di flag.

There have been a few other recent bug fixes that have been giving me enough headaches for me to want to try it it out. By the looks of things, if I'm to make real use out of D, I'll have to learn how to fix D as well.
 Also, some of us are hoping that the change to deprecated will 
 be reverted in
 favor of making it so that warnings will be the default for 
 using deprecated

Yes, that's what makes the most sense.
 symbols rather than having error be the default. Having -di is 
 nice, but it
 really doesn't fix much. The main problem (at least from the 
 library writer's
 point of view) is that deprecating anything instantly breaks 
 the code of
 anyone using that the now deprecated symbol. -di makes it so 
 that a programmer
 can protect themselves from that, but it still shackles the 
 library writer
 such that they can't deprecate anything if they don't ever want 
 to break
 anyone's code without giving more warning that a note in the 
 changelog or
 documentation.

This subject always makes me think of Python, however, it also reminds me of the trap C++ fell into. Personally, I prefer dealing with a few breaking changes now and then rather than sticking with not-so-good decisions forever. In terms of man hours wasted, sticking with a poor design choice can eat up far more man hours over the years than the time taken to deal with a real fix. But I do understand both sides of the coin having been there myself. IMO, so long as you can stick with an older version of the compiler and library for legacy code, you're OK. You guys may want to ensure that older version of a library and compiler can easily co-exist on the same OS installation as a part of the solution to the deprecation breakage dilemma. If a programmer could choose both the compiler version, and a library version for importing into his source code, that would be excellent. --rt
Nov 14 2012