www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - shouldn't override be obligatory?

reply Trass3r <un known.com> writes:
so you don't accidentally override a base class method without knowing it.
Mar 13 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Trass3r:
 so you don't accidentally override a base class method without knowing it.

I'm trying to help D become tidier, I have added this days ago: http://d.puremagic.com/issues/show_bug.cgi?id=3836 Bye, bearophile
Mar 13 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Trass3r" <un known.com> wrote in message 
news:op.u9i1zxqa3ncmek hoenir.fem.tu-ilmenau.de...
 so you don't accidentally override a base class method without knowing it.

I read about "override" when I first got into D way back before D1.0 and thought it sounded great. Then I promptly forgot about it since the compiler never complained, and I haven't even thought to use it since. I suspect I'm not the only one that's happened to. Therefore, if there's potential benefit to be gained from "override" (and I believe that there is), then I don't think we're actually *getting* much of that benefit as things currently are. Although, as far as whether or not that benefit is worth the bother of it being required, well, I haven't given any thought to that in a long time, so I'm really not sure either way, ATM.
Mar 13 2010
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hnh4kl$1iqo$1 digitalmars.com...
 "Trass3r" <un known.com> wrote in message 
 news:op.u9i1zxqa3ncmek hoenir.fem.tu-ilmenau.de...
 so you don't accidentally override a base class method without knowing 
 it.

I read about "override" when I first got into D way back before D1.0 and thought it sounded great. Then I promptly forgot about it since the compiler never complained, and I haven't even thought to use it since. I suspect I'm not the only one that's happened to. Therefore, if there's potential benefit to be gained from "override" (and I believe that there is), then I don't think we're actually *getting* much of that benefit as things currently are. Although, as far as whether or not that benefit is worth the bother of it being required, well, I haven't given any thought to that in a long time, so I'm really not sure either way, ATM.

Although, I will say that Haxe requires "override", and I've been writing a lot of Haxe lately, and I've never found it annoying there (other parts of Haxe I've found annoying...but not that ;) ).
Mar 13 2010
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-03-13 17:27:23 -0500, Trass3r <un known.com> said:

 so you don't accidentally override a base class method without knowing it.

It's my opinion that it should. (bugzilla 3836)++ -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 13 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/13/2010 04:27 PM, Trass3r wrote:
 so you don't accidentally override a base class method without knowing it.

It is in TDPL so it is in the language :o). Andrei
Mar 13 2010
prev sibling next sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Trass3r wrote:
 so you don't accidentally override a base class method without knowing it.

use -w: import std.stdio; class A { void foo() { writeln("A.foo"); } } class B : A { void foo() { writeln("B.foo"); } } void main() { A a = new B; a.foo(); }

but is not marked with 'override' I never compile without -w Strangely it doesn't give an error if A is an interface though. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLnPy/T9LetA9XoXwRAu29AKCKx4fRYE1OYFQmW9wBZ7Gs+orDzQCgghKz Q8pGjo99BzqrP0819h7p9yM= =QVzI -----END PGP SIGNATURE-----
Mar 14 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
div0 wrote:

 Strangely it doesn't give an error if A is an interface though.

Interfaces aren't overridden; they're implemented. You're providing functionality, not replacing it. By marking a function with override, you're clearly marking that it's polymorphic and intended to be so. If you force override for all cases when a function is overridden, then you avoid issues where you unknowingly override a function, changing the objects behavior. That's not a problem with interfaces since there's no behavior to change. The problem with interfaces is when you don't implement them completely, and they complain plenty when that happens. - Jonathan M Davis
Mar 14 2010
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathan M Davis wrote:
 div0 wrote:
 
 Strangely it doesn't give an error if A is an interface though.

Interfaces aren't overridden; they're implemented. You're providing functionality, not replacing it. By marking a function with override, you're clearly marking that it's polymorphic and intended to be so. If you force override for all cases when a function is overridden, then you avoid issues where you unknowingly override a function, changing the objects behavior. That's not a problem with interfaces since there's no behavior to change. The problem with interfaces is when you don't implement them completely, and they complain plenty when that happens. - Jonathan M Davis

True, but using override clearly documents what you doing in that class. Otherwise you have to arse about looking through the interfaces to see if an unmarked function is an implementation, which is the same end result as unmarked overrides. I vote for requiring override in all cases; I think it makes things clearer. YMMV. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLnq2vT9LetA9XoXwRApt6AJ90pOplStRil47vz86z21kqw3r/xgCbB/VW aKiRACV/f3Y3fwHevLD8omo= =xClh -----END PGP SIGNATURE-----
Mar 15 2010
parent Jonathan M Davis <jmdavisProg gmail.com> writes:
div0 wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Jonathan M Davis wrote:
 div0 wrote:
 
 Strangely it doesn't give an error if A is an interface though.

Interfaces aren't overridden; they're implemented. You're providing functionality, not replacing it. By marking a function with override, you're clearly marking that it's polymorphic and intended to be so. If you force override for all cases when a function is overridden, then you avoid issues where you unknowingly override a function, changing the objects behavior. That's not a problem with interfaces since there's no behavior to change. The problem with interfaces is when you don't implement them completely, and they complain plenty when that happens. - Jonathan M Davis

True, but using override clearly documents what you doing in that class. Otherwise you have to arse about looking through the interfaces to see if an unmarked function is an implementation, which is the same end result as unmarked overrides. I vote for requiring override in all cases; I think it makes things clearer. YMMV.

I know that that has caused problems in Java with their override attribute. I don't want to see those in D. Unfortunately, I haven't been using Java much lately, so I can't list the problems off the top of my head, but there are definitely problems with using override on interface functions. As such, I'd be highly opposed to doing so. If we wanted that, I think that it would make far more sense to add an implements attribute for interface functions. And on top of that, you're never going to run into a problem with a function implementing an interface when you don't mean it to while you _are_ going to run into problems with functions accidentally overriding other functions (assuming that there's no check based on override). From the standpoint of code correctness and bugs, and I see zero benefit in explicitly marking functions which implement interfaces, while I see great benefit in having to explicitly mark functions as overriding other functions. - Jonathan M Davis
Mar 15 2010
prev sibling parent Trass3r <un known.com> writes:
 True, but using override clearly documents what you doing in that class.
 Otherwise you have to arse about looking through the interfaces to see
 if an unmarked function is an implementation, which is the same end
 result as unmarked overrides.

 I vote for requiring override in all cases; I think it makes things
 clearer. YMMV.

I guess that could be a custom annotation/attribute (if that's going to come sometime) so it doesn't pollute the language.
Mar 15 2010