Berin Loritsch wrote:
> I am enjoying the conversation BTW.
> 
> Andy Friesen wrote:
> 
>  > It is a problem is that there's no straightforward way to contractually
>  > force an override to call the superclass method it overrides, but that's
>  > neither here nor there.
> 
> I think requiring this is more elegant than forcing a keyword to be used everywhere.  More on that later.

I think I see what you are talking about.  The trouble is that you're talking about something completely different. ;)

Kris's problem had to do with creating a method that had absolutely nothing at all to do with Thread.pause().  There was absolutely no semantic link, or intent/desire to call super.pause() because Kris wasn't even aware that it existed.

The problem is that DMD didn't say a word, because there is no requirement that a method specifically be denoted as an override.  Kris overrode Thread.pause() without even realizing it: fireworks ensued.

If the override keyword were mandatory, this would have not been a problem: it would be a compile error.

> :)  In D, value_type and int are two different things.  In C++ they are
> the same thing--so this is something that can be a source of confusion.
> Esp. if there is an implicit conversion from int to value_type (the C++
> way).
> 
> I can understand there being an issue here, and the possibility of requiring the override keyword in this case.

My point was that, whether or not it's a bug, to a person, it looks like it *could* be a bug, but you can't be sure.  If it looks like a bug, you run the risk of someone "fixing" it.

> On requiring the keyword all the time:
> -------------------------------------
> 
> 	Label m_label = new Label("see");
> 
> Most people, even experienced developers, can miss it.  Its because seeing the word "Label" starts looking like noise, so the brain just
> throws out the one that redeclares the variable within the method.

This isn't a problem: if you denote every method as being an override, the compile will (rightly) fail.

 -- andy

There is no denying that its a potential problem. I wonder how often the problem is occurs in practice though. Part of the problem is checkking the APIs you use, part of the problem is that the API can change. There are good reasons for using override but I haven't heard a really good reason for making it compulsory. I find it rather counterproductive to write a list of names in favor of your position, even if it is the most popular and you might be right.

Arcane Jill wrote:


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

I would vote for (2) or (4). I'm not voting for you choice (3) for a simple
stadistical and byte-economy reason: In my experience when I've written a
subclass usually there were more non-overriding methods than overriding
ones (except if the base class was abstract, of course). But this is only a
"soft" preference and I would be happy with any of (2), (3) or (4).

Bent Rasmussen wrote:

> There is no denying that its a potential problem. I wonder how often the problem is occurs in practice though. Part of the problem is checkking the APIs you use, part of the problem is that the API can change. There are good reasons for using override but I haven't heard a really good reason for making it compulsory. I find it rather counterproductive to write a list of names in favor of your position, even if it is the most popular and you might be right.

From a previous message from Daniel Horn:

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

This has also bitten my on Python (where functions of subclasses with the same name always override) more times that I would have liked. Making "override" compulsory doesn't really change too much in the current definition of the language but it can avoid a good number of (sometimes very hard to find) bugs.

"Bent Rasmussen"wrote ...
> making it compulsory. I find it rather counterproductive to write a list
of
> names in favor of your position, even if it is the most popular and you might be right

That was intended only to place the implied importance of Berin's "experience" claim into perspective for him. But I may have stretched the point, and you make a fair comment.

Perhaps there's an whiff of this going on <g>: http://www.ars-technica.com/news/posts/20040717-4003.html

- Kris

Andy Friesen wrote:



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

True, great interview. I'm a little on the middle side about checked exceptions. I think they could be one of the places where (with some parameter, like -Wuncatched or -Euncatched) it could have sense to have compiler warnings, or just errors, like:

"Warning||Error: method cl.foo (line 300) can throw FooException and and
you're not catching it."

Then you could decide if you need to catch the exception or not (because depending of how you use cl.foo FooException it could be impossible to trigger FooException, or you just want the program to abort in that case)

Wouldn't that be nice?

In fact, one of the projects I've on my long "TODO" list is a program (or a patch to pychecker) to show these warnings on Python code.

Bent Rasmussen wrote:
> There is no denying that its a potential problem. I wonder how often the
> problem is occurs in practice though. Part of the problem is checkking the
> APIs you use, part of the problem is that the API can change. There are good
> reasons for using override but I haven't heard a really good reason for
> making it compulsory. I find it rather counterproductive to write a list of
> names in favor of your position, even if it is the most popular and you
> might be right.
> 
> 

otherwise you forget
you can better believe in the beginning stages of Vega Strike development anything that was NOT manditory was ignored

and I paid for it later...
had the override option been manditory in C++, I would not have gotten burned by the missile thing...and the missile collision check was not the only thing--there have been at least 15 bugs that were exactly the same in Vega Strike over the years...
I could name them one by one, but I think it would bore you...

and VS is a young project... imagine what might happen in a more OO-based project that's older...

Arcane Jill wrote:
> (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.

So, something like:

    class A {
        void foo() { ... } // ok.  no such thing as Object.foo()
    }
    class B {
        void bar() { ... } // ok.  No A.bar() or Object.bar()
        void foo() { ... } // ok.  overrides A.foo()
        int foo(float f) { ... } // no.  A.foo() exists and this method cannot override it
        new int foo(float f) { ... } // we must write it like so
    }

This does clear things up exactly the same way as the override keyword, but (I've said this before, I'm sure) I think it's a better idea to have that positive assertion that the method is supplanting or augmenting behaviours defined in an ancestor class.

'new' methods tell you is that there's some stuff in the base class that is sort of superficially similar, and that the method has nothing to do with that.

The concept almost reminds me of a Monty Python sketch or somesuch. "See that thing over there?  The little wee spec waaaay off in the distance?  Well, it's completely unrelated to what we're doing here, so stop staring."

It makes more sense to me if D forces us to emphasize the links which are there, as opposed to the ones which are not. :)

 -- andy

Juanjo Álvarez wrote:

> Andy Friesen wrote:
>>There's a *great* interview on artima with Anders Hejlsberg on this
>>issue.  <http://www.artima.com/intv/handcuffs.html>
> 
> True, great interview. I'm a little on the middle side about checked
> exceptions. I think they could be one of the places where (with some
> parameter, like -Wuncatched or -Euncatched) it could have sense to have
> compiler warnings, or just errors, like:
> 
> "Warning||Error: method cl.foo (line 300) can throw FooException and and
> you're not catching it."
> 
> Then you could decide if you need to catch the exception or not (because
> depending of how you use cl.foo FooException it could be impossible to
> trigger FooException, or you just want the program to abort in that case) 
> 
> Wouldn't that be nice?
> 
> In fact, one of the projects I've on my long "TODO" list is a program (or a
> patch to pychecker) to show these warnings on Python code.

It's entirely reasonable to plow through a whole algorithm, expecting any thrown exceptions to be handled by the caller.  What's less reasonable is letting open sockets dangle around because of it.  (is there any reason at all to want this to occur?)

For this reason, it would be better if a warning was raised when the compiler can verifiably prove that such a resource would be left hanging in the case of an uncaught exception.  This gives us the chance to make sure we declared our autos as autos and put our finally clauses in place.

(the trick is telling the compiler what's expensive.  A pragma might be overkill for such a specific thing.  Maybe it's worth it)

 -- andy

+1
Andy Friesen wrote:
> Arcane Jill wrote:
> 
>> (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.
> 
> 
> So, something like:
> 
>     class A {
>         void foo() { ... } // ok.  no such thing as Object.foo()
>     }
>     class B {
>         void bar() { ... } // ok.  No A.bar() or Object.bar()
>         void foo() { ... } // ok.  overrides A.foo()
>         int foo(float f) { ... } // no.  A.foo() exists and this method cannot override it
>         new int foo(float f) { ... } // we must write it like so
>     }
> 
> This does clear things up exactly the same way as the override keyword, but (I've said this before, I'm sure) I think it's a better idea to have that positive assertion that the method is supplanting or augmenting behaviours defined in an ancestor class.
> 
> 'new' methods tell you is that there's some stuff in the base class that is sort of superficially similar, and that the method has nothing to do with that.
> 
> The concept almost reminds me of a Monty Python sketch or somesuch. "See that thing over there?  The little wee spec waaaay off in the distance?  Well, it's completely unrelated to what we're doing here, so stop staring."
> 
> It makes more sense to me if D forces us to emphasize the links which are there, as opposed to the ones which are not. :)
> 
>  -- andy