Kris wrote:

> I really like the override keyword. It works well as a reminder when you're
> refactoring classes. However, I'd like to see it extended such that it
> becomes /required/. 

Check out Stroustrup 'Design and Evolution of C++' for a discussion of why override was dropped from C++.

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

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.

Could you give us all a brief summary please Jonathan? It may not apply to D in the same manner ...

"Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:cdcf1n$1osa$2@digitaldaemon.com...
> Kris wrote:
>
> > I really like the override keyword. It works well as a reminder when
you're
> > refactoring classes. However, I'd like to see it extended such that it becomes /required/.
>
> Check out Stroustrup 'Design and Evolution of C++' for a discussion of why override was dropped from C++.
>
> --
> Jonathan Leffler                   #include <disclaimer.h>
> Email: jleffler@earthlink.net, jleffler@us.ibm.com
> Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Echoed.

I don't want to be a "Cabal" about this, but I've just scanned D&E and can find no mention of it. Overriding is specifically indexed at pages 76 and 293, neither of which talk about the keyword, but rather pertain to the issue of covariant return types.


"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdcjlr$1qor$1@digitaldaemon.com...
> Could you give us all a brief summary please Jonathan? It may not apply to D in the same manner ...
>
> "Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:cdcf1n$1osa$2@digitaldaemon.com...
> > Kris wrote:
> >
> > > I really like the override keyword. It works well as a reminder when
> you're
> > > refactoring classes. However, I'd like to see it extended such that it becomes /required/.
> >
> > Check out Stroustrup 'Design and Evolution of C++' for a discussion of why override was dropped from C++.
> >
> > --
> > Jonathan Leffler                   #include <disclaimer.h>
> > Email: jleffler@earthlink.net, jleffler@us.ibm.com
> > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
>
>
>

I like that its optional. Perhaps an IDE could help here.

Btw. (and a bit off topic) I just found this superb resource http://www.artima.com/articles/index.jsp?topic=intv

There's no D topic yet, but there are some very nice insigts, e.g. http://www.artima.com/intv/goldilocks3.html

Having the compiler detect non-virtual functions makes this style pleasant.

May I ask you to expound on your preference for optional please?

"Bent Rasmussen" <exo@bent-rasmussen.info> wrote in message news:cdclsk$1rlm$1@digitaldaemon.com...
> I like that its optional. Perhaps an IDE could help here.
>
> Btw. (and a bit off topic) I just found this superb resource http://www.artima.com/articles/index.jsp?topic=intv
>
> There's no D topic yet, but there are some very nice insigts, e.g. http://www.artima.com/intv/goldilocks3.html
>
> Having the compiler detect non-virtual functions makes this style
pleasant.
>
>

Matthew wrote:

> Echoed.
> 
> I don't want to be a "Cabal" about this, but I've just scanned D&E and can find
> no mention of it. Overriding is specifically indexed at pages 76 and 293, neither
> of which talk about the keyword, but rather pertain to the issue of covariant
> return types.

Beg pardon - the keyword was overload, not override (shaky memory - overloaded, I guess :-)

p226 refers - 11.2.2 Ambiguity Control.

Prior to C++ 2.0, there was a keyword 'overload' functioning as a storage class:
   overload void print(int);
   void print(double);
And the order of declaration controlled which function was used, which was 'trivial for implementors to get right, and was a constant source of errors and confusion.  Reversioing the declaration order could completely change the meaning of a piece of code: [...example...] Basically, order dependence was too error-prone.  It also became a serious obstacle to the effort to evolve C++ programming towards a greater use of libraries.'

There's a whole lot more, more particularly about what changed in 2.0 and beyond.

On second thoughts, it most probably does not apply to D - wrong keyword for one thing, and in any case 'override' probably applies in  a different context, and without the problems.

Sorry for disturbing the ether with a pointless message.

> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote:
>>Could you give us all a brief summary please Jonathan? It may not apply to D
>>in the same manner ...
>>
>>"Jonathan Leffler" <jleffler@earthlink.net> wrote:
>>>Kris wrote:
>>>>I really like the override keyword. It works well as a reminder when
>>>>you're
>>>>refactoring classes. However, I'd like to see it extended such that it
>>>>becomes /required/.
>>>
>>>Check out Stroustrup 'Design and Evolution of C++' for a discussion of
>>>why override was dropped from C++.


-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

"Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:cdd54f$222s$1@digitaldaemon.com...
> Matthew wrote:
>
> > Echoed.
> >
> > I don't want to be a "Cabal" about this, but I've just scanned D&E and can
find
> > no mention of it. Overriding is specifically indexed at pages 76 and 293,
neither
> > of which talk about the keyword, but rather pertain to the issue of covariant return types.
>
> Beg pardon - the keyword was overload, not override (shaky memory -
> overloaded, I guess :-)
>
> p226 refers - 11.2.2 Ambiguity Control.
>
> Prior to C++ 2.0, there was a keyword 'overload' functioning as a
> storage class:
>     overload void print(int);
>     void print(double);
> And the order of declaration controlled which function was used, which
> was 'trivial for implementors to get right, and was a constant source
> of errors and confusion.  Reversioing the declaration order could
> completely change the meaning of a piece of code: [...example...]
> Basically, order dependence was too error-prone.  It also became a
> serious obstacle to the effort to evolve C++ programming towards a
> greater use of libraries.'
>
> There's a whole lot more, more particularly about what changed in 2.0 and beyond.
>
> On second thoughts, it most probably does not apply to D - wrong
> keyword for one thing, and in any case 'override' probably applies in
>   a different context, and without the problems.
>
> Sorry for disturbing the ether with a pointless message.


He he. Rather than doing a "Cabal", you actually ended up doing a "Matthew". :)

No worries from my POV. It caused me to dip back into that wonderful book, which I've not done much of in years. FWIW, I think Dr Stroustrup is something of a prescient genius, despite the overload debacle. Several of the things I've "invented" in C++ in the last couple of years have been anticipated, in one way or another, by him several years before. My "Fast String Concatenation" technique was inspired by his technique for efficient matrix operations.


>
> > "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote:
> >>Could you give us all a brief summary please Jonathan? It may not apply to D in the same manner ...
> >>
> >>"Jonathan Leffler" <jleffler@earthlink.net> wrote:
> >>>Kris wrote:
> >>>>I really like the override keyword. It works well as a reminder when
> >>>>you're
> >>>>refactoring classes. However, I'd like to see it extended such that it
> >>>>becomes /required/.
> >>>
> >>>Check out Stroustrup 'Design and Evolution of C++' for a discussion of why override was dropped from C++.
>
>
> -- 
> Jonathan Leffler                   #include <disclaimer.h>
> Email: jleffler@earthlink.net, jleffler@us.ibm.com
> Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

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.

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