Russ Lewis wrote:

> 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.

Ok.  I'm used to it happening implicitly.  Since I do make use of inheritance, having to state that explicitly would be annoying to me.

> 
> 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.

When would you *not* override a base class function?  I don't get when you wouldn't want that to happen.

Berin Loritsch wrote:
> When would you *not* override a base class function?  I don't get when you wouldn't want that to happen.

Somebody (I forget who) had a problem where he added a pause() function to one of his classes.  However, he later discovered that the class Thread (which, 3 levels back, was a base class of this guy's class) also had a pause() function.  So when some thread code called pause(), it got his pause() function...which definitely does NOT pause the thread.

Berin Loritsch wrote:

> Russ Lewis wrote:
> 
>> 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.

I disagree with this completely.

Implementation inheritance is a tricky problem because you not only have a public interface, you have a private invariant that must be maintained.  If any method can be overridden, your job gets a whole lot harder.

It's better to keep a tight leash on classes and design it such that the only non-final methods are the ones which were made to be non-final. (I prefer to write interfaces and abstract boilerplate classes.  No actual method overriding involved)

>> The question is not whether a function is overridABLE.  It is whether the function is overridING.
> 
> Ok.  I'm used to it happening implicitly.  Since I do make use of inheritance, having to state that explicitly would be annoying to me.

The problem is that, when that explicit annotation is not present, changing method signatures in some base class can cause complete chaos because of all sorts of methods which aren't actually overriding anything.  Nonetheless, it's all legal syntax, and typically compiles just fine.

I think this is a case where it is so easy to do the wrong thing that it is worthwhile to demand that extra bit of explicitness.

> When would you *not* override a base class function?  I don't get when you wouldn't want that to happen.

This problem arises in C# sometimes.  It basically amounts to wanting to use some method signature which happens to conflict with another method defined in a dark corner of a superclass someplace.  Your method has absolutely nothing to do with that one, save the signature, and you'd rather not be forced to kludge around it by renaming it.

 -- andy

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. 

There's a *great* interview on artima with Anders Hejlsberg on this issue.  <http://www.artima.com/intv/handcuffs.html>

Basically, it amounts to two big things:  programmers are lazy oafs (it takes one to know one) and will circumvent checked exceptions, and that most people just want the exception to a toplevel error handler, so the error can be reported to the user in one place.  Try/finally blocks ensure that everything gets released properly on such an occasion.

Besides, all that error checking is a lot of code.  The whole point of exceptions is to make sure that error checking is NOT a lot of 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 feel pretty confident saying that, if it's a pain in the ass, then the tools didn't do their job.  (in their defense, they have hard jobs: there are lots of common problems for which there are no sufficiently powerful tools)

 -- andy

I was refactoring Vega Strike (http://vegastrike.sourceforge.net/ ) to divide graphics and physics. This happened countless times in the process :-/ )

Many times were the opposite case, where I had functions that originally overrode other functions and then they stopped overriding them (because of overloading rules).
if those functions had had override  as a keyword before my refactor the compiler would have helped me discover those problems.
As it turns out missiles were not working for a YEAR before I found that they were not properly working and then identified the problem as being that their collide() function was not working as intended because it was not being overridden any more.

I strongly recommend doing this override thing *before* 1.0
-Daniel

Russ Lewis wrote:
> 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.
> 

Andy Friesen wrote:

> Berin Loritsch wrote:
> 
>> Russ Lewis wrote:
>>
>>> 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.
> 
> 
> I disagree with this completely.

Which part?  The part that says I have to explicitly state "I want to override" for each class/interface method from a parent class I might be working on?  Or the part that says overriding is expected unless told otherwise?

> 
> Implementation inheritance is a tricky problem because you not only have a public interface, you have a private invariant that must be maintained.  If any method can be overridden, your job gets a whole lot harder.

I really haven't run into this problem, and I have developed software
for a few years now.  Mostly Java and C++.  I run into more problems because a language (or compiler in some cases) *doesn't* override a method I expect it to.

> 
> It's better to keep a tight leash on classes and design it such that the only non-final methods are the ones which were made to be non-final. (I prefer to write interfaces and abstract boilerplate classes.  No actual method overriding involved)

This is more a policy of development style and methodology than anything else.  I don't believe a language should restrict a user unnecesarily. The purpose of any language is to enable them to solve problems they could not solve before, or were very inconvenient to solve before.

> 
>>> The question is not whether a function is overridABLE.  It is whether the function is overridING.
>>
>>
>> Ok.  I'm used to it happening implicitly.  Since I do make use of inheritance, having to state that explicitly would be annoying to me.
> 
> The problem is that, when that explicit annotation is not present, changing method signatures in some base class can cause complete chaos because of all sorts of methods which aren't actually overriding anything.  Nonetheless, it's all legal syntax, and typically compiles just fine.

Does this happen often?  Once a project reaches a certain level of maturity, I rarely see a need to change a base class method name.

Look at it this way:

A method that does not call super.methodName() isn't overriding a method, it is replacing it.  Any call to super.methodName() will
cause a compile error if super.methodName() does not exist.

Translate that into D syntax if that isn't right.

If there is a true override instead of a replacement, then yes, the
compiler will complain loudly.  Or at least it should.

> 
> I think this is a case where it is so easy to do the wrong thing that it is worthwhile to demand that extra bit of explicitness.

I don't think it is as easy to do wrong as you think, unless there is a bug in the compiler.

> 
>> When would you *not* override a base class function?  I don't get when you wouldn't want that to happen.
> 
> 
> This problem arises in C# sometimes.  It basically amounts to wanting to use some method signature which happens to conflict with another method defined in a dark corner of a superclass someplace.  Your method has absolutely nothing to do with that one, save the signature, and you'd rather not be forced to kludge around it by renaming it.

IMO, if you have this situation, then the work should be split into two separate classes.  No reason to have separate semantics for one method.  It is just one more place where maintenance can go wrong.

Russ Lewis wrote:

> Berin Loritsch wrote:
> 
>> When would you *not* override a base class function?  I don't get when you wouldn't want that to happen.
> 
> 
> Somebody (I forget who) had a problem where he added a pause() function to one of his classes.  However, he later discovered that the class Thread (which, 3 levels back, was a base class of this guy's class) also had a pause() function.  So when some thread code called pause(), it got his pause() function...which definitely does NOT pause the thread.

So he did not override a method, he replaced the method?

He should have placed a call to super.pause() to have everything working as expected.  However that is done in D.

Berin Loritsch wrote:

> Russ Lewis wrote:
> 
>> Berin Loritsch wrote:
>>
>>> When would you *not* override a base class function?  I don't get when you wouldn't want that to happen.
>>
>>
>>
>> Somebody (I forget who) had a problem where he added a pause() function to one of his classes.  However, he later discovered that the class Thread (which, 3 levels back, was a base class of this guy's class) also had a pause() function.  So when some thread code called pause(), it got his pause() function...which definitely does NOT pause the thread.
> 
> 
> So he did not override a method, he replaced the method?
> 
> He should have placed a call to super.pause() to have everything working as expected.  However that is done in D.

What about a compiler warning/error if a method overrides a base class method, but never calls super.methodName()?

Andy Friesen wrote:
> 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. 
> 
> 
> There's a *great* interview on artima with Anders Hejlsberg on this issue.  <http://www.artima.com/intv/handcuffs.html>
> 
> Basically, it amounts to two big things:  programmers are lazy oafs (it takes one to know one) and will circumvent checked exceptions, and that most people just want the exception to a toplevel error handler, so the error can be reported to the user in one place.  Try/finally blocks ensure that everything gets released properly on such an occasion.
> 
> Besides, all that error checking is a lot of code.  The whole point of exceptions is to make sure that error checking is NOT a lot of code.

Apart from this, checked exceptions are not compatible with interfaces. The whole point of an interface is to abstract from the implementation. But if you have to specify which kinds of errors can occur then you have to foresee any error that could occur in any future implementation - which is impossible, of course.

Hauke

In article <cdh400$kov$3@digitaldaemon.com>, Berin Loritsch says...

Berin, I think you've misunderstood. May I take the trouble to explain things? First, here's the status quo: The "override" keyword is /not/ compulsory. This means that you have a choice of two different ways of writing things. Version one:

#    class A
#    {
#        void f();
#    }
#
#    class B : A
#    {
#        void f();
#    }
#
#    // and now for some polymorphism
#    A a = new B();
#    a.f(); // calls B.f();

This works fine. And now, here's version 2:

#    class A
#    {
#        void f();
#    }
#
#    class B : A
#    {
#        override void f();
#    }
#
#    // and now for some polymorphism
#    A a = new B();
#    a.f(); // calls B.f();

The difference? Well, right now, none at all. Both versions do exactly the same thing. BUT - suppose that, at some point in the future, some developer modifes class A (but not class B) so that class A becomes:

#    class A
#    {
#        void f(bool b);
#    }

Now /this/ is where the override keyword comes in, because now, version 1 will still compile, but version 2 will not. Trouble is, version 1 now contains a bug, because polymorphism has now stopped working, contrary to the programmer's expectations. Thus:

#    // and now for some FAILED polymorphism
#    A a = new B();
#    a.f(false); // Whoops! - Calls A.f();, not B.f()

So how is the designer of class B ever supposed to know that the base class signature has changed? Wait for a bug report? "override" gives you a way of being notified of the need to change your code (next time you compile the source).

So, "override" is very, very useful, as it can help you find bugs which otherwise you might miss for years, and the /absence/ of the "override" keyword could be viewed as a bug waiting to happen. So some people have proposed on this thread that the keyword be compulsory.

Another school of thought is that the compiler should always behave /as if/ the "override" keyword had been present, so you never actually have to type it. However, there are times when you /do/ want to provide a function with the same name, but a different signature from, a base class. In D the philosophy seems to be to /encourage/ people to do the "right thing", but nonetheless to allow them to do something a bit different if they really need to. Which brings me to your question:

>When would you *not* override a base class function?  I don't get when you wouldn't want that to happen.

There's a really neat example of this in my class Int (unlimited precision
integers). It's a class, so it derives from Object. Object defines opEquals() as
having this signature:

#    int opEquals(Object obj)

Just in case Walter should ever decide to change this signature, within Int I declare:

#    override int opEquals(Object obj)

however, in addition to this, I /also/ provide a same-name-different-signature function, which does /not/ override any function in Object. It is this:

#    int opEquals(int n)

Why would I do this? Well because it allows users of my class to write tests such as:

#    // Int n
#    if (n == 42)

instead of the more cumbersome (and less efficient)

#    if (n == new Int(42))

So, /sometimes/ you don't want to override, but /usually/ you do, and /usually/ it's a bug waiting to happen if you don't (because someone might change the base class without your knowledge).

With that in mind, the possibilities at our disposal are:

(1) the status quo - "override" implies an override; no keyword implies nothing
at all (so it might or might not be an override)

(2) as (1), except that the keyword "override" is now compulsory whenever
overriding.

(3) my suggestion - that the behavior currently enabled by the keyword "override" be the default behavior, and that, therefore, the keyword itself becomes redundant and may be dropped. A side-effect of this is that we'd then need a new keyword to do something /other/ than the default.

(4) require an explicit keyword for each and every possibility.

Changes such as this can be made (by Walter) with ease right now, but post v1.0 the syntax is supposed to be frozen in concrete, so this is almost our last chance to press for changes in syntax. Walter is amenable to suggestions, but only if he thinks they're a good idea. (He's not swayed by a mere majority vote - you actually have to /convince/ him).

Arcane Jill