Arcane Jill wrote:
> Maybe another approach might work. How about this:
> (1) Ditch the "override" keyword - member functions override by default.
> (2) Introduce a new keyword to allow same-name-different-signature functions.
> Just as a thought, the keyword "new" springs to mind as possibly appropriate.

Both approaches would have about the same effect on the writability of the code, but it seems to me that 'override', as an explicit annotation declaring that the function supplants base class functionality, does much more for the readability.

 -- andy

Thanks; yeah, an editor doing that would be very nice (I'm lazy too). But from a strategic perspective it makes sense for the compiler to be strict about it; the latter would provide a good bargaining chip for getting D into the commercial sector (where long-term maintenance is /truly/ an issue).

- Kris

"Bent Rasmussen" <exo@bent-rasmussen.info> wrote in message news:cdeigq$2isd$1@digitaldaemon.com...
> I'm lazy and haven't run into a situation as you describe, or if so, it hasn't passed the irritation threshold, but then my programs tend not to
be
> large. I'd rather have an editor inform me of overrides than write "override" next to every overridden function just in case. Personal preference.
>
>

Ditching the "override" would lose one of the key benefits. In fact it would lose the only benefit it has right now: namely the ability for the compiler to point out that the your method is no longer overriding a super-class instance (that's what it does at this point). The compiler depends upon the explicit annotation to catch this.

Lets not even begin to talk about the lack of method signature-matching that's grossly missing under various scenarios ... that's another topic altogether. One that I'll write an Exposé upon soon, since it needs to be fixed before any sane commercial venture would touch the language/compiler.

 - Kris


"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cdeppu$2m2o$1@digitaldaemon.com...
> In article <cdcbrr$1np2$1@digitaldaemon.com>, Vathix says...
> >
> >I always use override; this sounds good to me.
>
> And I. (Well, almost - see below). Now, pardon me for taking this
reasoning one
> step further, but, if override is to be compulsory, then we don't actually
need
> the keyword, do we?
>
> That is, if it is to be compulsory that a function in a derived class
which has
> the same name as a function in a base class must have the same signature
(which
> is what "override" dictates), then we might as well simply have the
compiler
> enforce this at all times - in which case the keyword "override" becomes entirely redundant. We can dispense with it. Throw it away.
>
> But ... might there be times when you /want/ a subclass to provide a
same-name
> function with a different signature? I can think of a good example - my
Int
> class sensibly overrides (with override keyword in place) the function
> opEquals(Object) ... but it /also/ has a function opEquals(int), allowing
you to
> write stuff like:
>
> #    Int n;
> #    if (n == 4)  // calls opEquals(int)
>
> Now, I agree with majority opinion here, in the sense that overriding is
what
> you /normally/ want to do. But, like everything else, sometimes there are exceptions.
>
> Maybe another approach might work. How about this:
> (1) Ditch the "override" keyword - member functions override by default.
> (2) Introduce a new keyword to allow same-name-different-signature
functions.
> Just as a thought, the keyword "new" springs to mind as possibly
appropriate.
>
> Arcane Jill
>
>
>
>

"teqDruid" <me@teqdruid.com> wrote in message news:pan.2004.07.17.22.24.00.469883@teqdruid.com...
> I think this is a great idea.
>

Take my vote too. +1

> Maybe another approach might work. How about this:
> (1) Ditch the "override" keyword - member functions override by default.
> (2) Introduce a new keyword to allow same-name-different-signature
functions.
> Just as a thought, the keyword "new" springs to mind as possibly
appropriate.

Delphi (ultimately where C# got it's override keyword from, as Anders also designed the Delphi Pascal dielect based Borland Object Pascal dialect) uses:

"virtual" to mark a method as virtual (can be overriden)
"override" to override the method (a warning if you don't do this since
Delphi 4)
"reintroduce" to redefie a  method with the same name but different
signature (since Delphi 4, before that the compiler really didn't seem to
care ;-)

(there's also "dynamic" which is the same as virtual, except it uses chaining rather than an explicit VMT to look up the inherited method call.)

We also have an "overload" keyword for method overloading.

This makes the whole business of inheritence and polymorphism very clear. Love it or hate it, it's very hard to make a mistake.

Perhaps we need to add the almost-keyword:
	!override
Then we have 3 types of functions:
	For good, explicit design:
		Must-be-override functions
		Must-not-be-override functions
	For rapid prototyping, and learning D:
		Unspecified functions

And, happily, we don't break any existing codebase.

Thoughts?

On Sun, 18 Jul 2004 02:14:59 +0200, Juanjo Álvarez wrote:

> Derek wrote:
> 
> 
>> If this understandng is correct, then I support the idea of the _override_ keyword having to be mandatory. It will cause less bugs in code, without a doubt, and at very little cost to the coder.
> 
> I totally agree; after all it's not like the burden of Java forcing the programmmers to explictly declare all the exceptions that a method can throw (as an example) but a simpler thing, want to override? use "override". Makes sense.

Actually, although having to continually write throws ... in my code is a pain, I rather like that Java requires the caller to write a try-catch block.  While this is also a pain, it makes for better, more stable code. I believe it's a general rule in programming that writing stable code to deal with all situations is a pain in the ass.

Russ Lewis wrote:

> Perhaps we need to add the almost-keyword:
>     !override
> Then we have 3 types of functions:
>     For good, explicit design:
>         Must-be-override functions
>         Must-not-be-override functions
>     For rapid prototyping, and learning D:
>         Unspecified functions
> 
> And, happily, we don't break any existing codebase.

What's wrong with having all functions/methods being overridable
unless there is a keywords saying don't do it?  This is something
that works quite happily in the Java lanaguage.

Having to explicitly say "I want this to be overriden" is quite
annoying, as most of the time that is what I expect.

Of course another C++ism that I have found annoying is that you
can have multiple methods have the same signature because of different
placements of "const" etc.  C# makes things a bit more confusing because
you can have one method act one way when accessed through one interface,
and another way when accessed through a different interface.

I just like the simple one method to one signature relationship in
Java.  It's simple, and it isn't too hard to deal with.

Just my 2 cents.

teqDruid wrote:

> On Sun, 18 Jul 2004 02:14:59 +0200, Juanjo Álvarez wrote:
> 
> 
>>Derek wrote:
>>
>>
>>
>>>If this understandng is correct, then I support the idea of the
>>>_override_ keyword having to be mandatory. It will cause less bugs in
>>>code, without a doubt, and at very little cost to the coder.
>>
>>I totally agree; after all it's not like the burden of Java forcing the
>>programmmers to explictly declare all the exceptions that a method can
>>throw (as an example) but a simpler thing, want to override? use
>>"override". Makes sense.
> 
> 
> Actually, although having to continually write throws ... in my code is a
> pain, I rather like that Java requires the caller to write a try-catch
> block.  While this is also a pain, it makes for better, more stable code. I believe it's a general rule in programming that writing stable code to
> deal with all situations is a pain in the ass.

I do like checked exceptions, but I have to admit that many times the API defines a checked exception where a runtime would have been better.

They should be used few and far between.

Berin Loritsch wrote:
> What's wrong with having all functions/methods being overridable
> unless there is a keywords saying don't do it?  This is something
> that works quite happily in the Java lanaguage.
> 
> Having to explicitly say "I want this to be overriden" is quite
> annoying, as most of the time that is what I expect.

The question is not whether a function is overridABLE.  It is whether the function is overridING.

Putting 'override' on a function means that it must override some base class function.  This is an easy way to check that you're actually overriding a base class function.

The question at hand in this thread is whether or not there should be some way to explicitly say that you are NOT overriding a base class function.  If you happen to accidentally override a base class function - and you don't know what that function is supposed to do - then you are practically guaranteed to have a bug, and you won't know about it until runtime.