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/. This would be in keeping with its current meaning, and may also resolve some of the issues surrounding the need to use an alias to pull in superclass methods of the same basic name (which is criminal in my opinion, but a different battle).

Anyway; if override were required it would catch a number of subtle bugs in derived classes. For example, I was refactoring some classes in Mango and decided to rename a couple of methods to pause() and resume() because that suited their behavior much better than the previous names. A few days later I started noticing odd program-termination behaviour, and just couldn't track it down. The MSVC debugger couldn't even help me.

Turns out that the class with the renamed methods was three levels removed
from a base class of (you guessed it) ... Thread. I had inadvertently
overridden the Thread.pause() and Thread.resume().  On win32 it didn't cause
a disaster, but on linux it caused segfaults during shutdown and/or thread
termination. Fancy that :-)

Now this is in my own library. Imagine the crap that will inevitably hit the fan in a long-term maintenance scenario? I think this is a great opportunity for D to shine in this arena; typing in the override keyword is no biggie for overriding methods, given the potential two-way benefit (refactoring and inadvertent-override).

I think it should be mandated by the compiler; an overriding method without the override keyword should result in a compile time error. What say you?

- Kris

You know me, the more strictly maintenance is supported, the better.

Of course, you realise it's not going to happen, don't you ...

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdatji$17fc$1@digitaldaemon.com...
> 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/. This would be in keeping with its current meaning, and may also resolve some of the issues surrounding the need to use an alias
to
> pull in superclass methods of the same basic name (which is criminal in my opinion, but a different battle).
>
> Anyway; if override were required it would catch a number of subtle bugs
in
> derived classes. For example, I was refactoring some classes in Mango and decided to rename a couple of methods to pause() and resume() because that suited their behavior much better than the previous names. A few days
later
> I started noticing odd program-termination behaviour, and just couldn't track it down. The MSVC debugger couldn't even help me.
>
> Turns out that the class with the renamed methods was three levels removed
> from a base class of (you guessed it) ... Thread. I had inadvertently
> overridden the Thread.pause() and Thread.resume().  On win32 it didn't
cause
> a disaster, but on linux it caused segfaults during shutdown and/or thread termination. Fancy that :-)
>
> Now this is in my own library. Imagine the crap that will inevitably hit
the
> fan in a long-term maintenance scenario? I think this is a great
opportunity
> for D to shine in this arena; typing in the override keyword is no biggie for overriding methods, given the potential two-way benefit (refactoring
and
> inadvertent-override).
>
> I think it should be mandated by the compiler; an overriding method
without
> the override keyword should result in a compile time error. What say you?
>
> - Kris
>
>

"Matthew Wilson" wrote in message
> You know me, the more strictly maintenance is supported, the better. Of course, you realise it's not going to happen, don't you ...

Any particular reason why not Matthew? After all, it's a simple change that makes D a more robust language for commercial usage. I've yet to hear a realistic negative against the notion ...

The obvious problem with the compiler making such an enforcement is that of backward compatibility. As it stands, the body of D code right now is small enough to manage such a change. That will not (hopefully) be the case with a version 2 of the language. Now is the time to do it, if ever. Personally I'd be more than glad to spend a half hour or so patching the 1.2MB of Mango source given the potential time-savings and lessened headaches for both myself and for everyone who ever uses (or maintains) Mango down the road. I would have thought you'd be a staunch advocate given that you're developing a toolkit also <g>

In addition to catching refactoring and inadvertent-override problems, a third benefit relates to adding methods to say, a library base-class, where you don't know what potential subclass method names might be. In such a scenario the compiler would at least pinpoint where the new library version conflicts with the 'client' method names (when the client compiles against the new codebase). That would also be highly beneficial IMHO.

Three real benefits; and almost free. Not to mention a possibly safe passage out of the alias quagmire WRT overloaded method names.

What sayeth thou? And thee, Walter?

Kris wrote:
> "Matthew Wilson" wrote in message
> 
>>You know me, the more strictly maintenance is supported, the better.
>>Of course, you realise it's not going to happen, don't you ...
> 
> 
> Any particular reason why not Matthew? After all, it's a simple change that
> makes D a more robust language for commercial usage. I've yet to hear a
> realistic negative against the notion ...
> 
> The obvious problem with the compiler making such an enforcement is that of
> backward compatibility. As it stands, the body of D code right now is small
> enough to manage such a change. That will not (hopefully) be the case with a
> version 2 of the language. Now is the time to do it, if ever. Personally I'd
> be more than glad to spend a half hour or so patching the 1.2MB of Mango
> source given the potential time-savings and lessened headaches for both
> myself and for everyone who ever uses (or maintains) Mango down the road. I
> would have thought you'd be a staunch advocate given that you're developing
> a toolkit also <g>
> 
> In addition to catching refactoring and inadvertent-override problems, a
> third benefit relates to adding methods to say, a library base-class, where
> you don't know what potential subclass method names might be. In such a
> scenario the compiler would at least pinpoint where the new library version
> conflicts with the 'client' method names (when the client compiles against
> the new codebase). That would also be highly beneficial IMHO.
> 
> Three real benefits; and almost free. Not to mention a possibly safe passage
> out of the alias quagmire WRT overloaded method names.
> 
> What sayeth thou? And thee, Walter?

I think requiring the override keyword is a great idea.  C# does exactly this, and it works fantastically.

The only way this could possibly cause any pain is when you forget to use the keyword on something you are intentionally overriding.  This is pretty miniscule in the face of all the headaches it can save: the compiler can trivially generate a useful error message, and it only takes one extra keyword to fix it.

With respect to backwards compatibility, there will never be a better time to change D than right now.  Ever.  Changing D after 1.0 will have to be done in a much more careful manner once that commitment to stability has been made.

 -- andy

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdbtc5$1hum$1@digitaldaemon.com...
> "Matthew Wilson" wrote in message
> > You know me, the more strictly maintenance is supported, the better. Of course, you realise it's not going to happen, don't you ...
>
> Any particular reason why not Matthew? After all, it's a simple change that makes D a more robust language for commercial usage. I've yet to hear a realistic negative against the notion ...
>
> The obvious problem with the compiler making such an enforcement is that of backward compatibility. As it stands, the body of D code right now is small enough to manage such a change. That will not (hopefully) be the case with a version 2 of the language. Now is the time to do it, if ever. Personally I'd be more than glad to spend a half hour or so patching the 1.2MB of Mango source given the potential time-savings and lessened headaches for both myself and for everyone who ever uses (or maintains) Mango down the road. I would have thought you'd be a staunch advocate given that you're developing a toolkit also <g>

I already said I want it. But I'm also a realist, and experience with D is that very few things which constrain the developer towards robustness and maintenance get in. Or am I being a cynic?

> In addition to catching refactoring and inadvertent-override problems, a third benefit relates to adding methods to say, a library base-class, where you don't know what potential subclass method names might be. In such a scenario the compiler would at least pinpoint where the new library version conflicts with the 'client' method names (when the client compiles against the new codebase). That would also be highly beneficial IMHO.
>
> Three real benefits; and almost free. Not to mention a possibly safe passage out of the alias quagmire WRT overloaded method names.
>
> What sayeth thou? And thee, Walter?

For the third time. Let's have it. Just don't go holding your breath.

And on that note of optimism, I must go away and write a plea for my own new keyword which I believe is absolutely necessary to the success of D(TL): autotype.

I think this is a great idea.

John

On Sat, 17 Jul 2004 03:06:53 -0700, 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/. This would be in keeping with its current meaning, and may also resolve some of the issues surrounding the need to use an alias to pull in superclass methods of the same basic name (which is criminal in my opinion, but a different battle).
> 
> Anyway; if override were required it would catch a number of subtle bugs in derived classes. For example, I was refactoring some classes in Mango and decided to rename a couple of methods to pause() and resume() because that suited their behavior much better than the previous names. A few days later I started noticing odd program-termination behaviour, and just couldn't track it down. The MSVC debugger couldn't even help me.
> 
> Turns out that the class with the renamed methods was three levels removed
> from a base class of (you guessed it) ... Thread. I had inadvertently
> overridden the Thread.pause() and Thread.resume().  On win32 it didn't
> cause a disaster, but on linux it caused segfaults during shutdown and/or
> thread termination. Fancy that :-)
> 
> Now this is in my own library. Imagine the crap that will inevitably hit the fan in a long-term maintenance scenario? I think this is a great opportunity for D to shine in this arena; typing in the override keyword is no biggie for overriding methods, given the potential two-way benefit (refactoring and inadvertent-override).
> 
> I think it should be mandated by the compiler; an overriding method without the override keyword should result in a compile time error. What say you?
> 
> - Kris

On Sat, 17 Jul 2004 03:06:53 -0700, 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/. This would be in keeping with its current meaning, and may also resolve some of the issues surrounding the need to use an alias to pull in superclass methods of the same basic name (which is criminal in my opinion, but a different battle).
> 
> Anyway; if override were required it would catch a number of subtle bugs in derived classes. For example, I was refactoring some classes in Mango and decided to rename a couple of methods to pause() and resume() because that suited their behavior much better than the previous names. A few days later I started noticing odd program-termination behaviour, and just couldn't track it down. The MSVC debugger couldn't even help me.
> 
> Turns out that the class with the renamed methods was three levels removed
> from a base class of (you guessed it) ... Thread. I had inadvertently
> overridden the Thread.pause() and Thread.resume().  On win32 it didn't cause
> a disaster, but on linux it caused segfaults during shutdown and/or thread
> termination. Fancy that :-)
> 
> Now this is in my own library. Imagine the crap that will inevitably hit the fan in a long-term maintenance scenario? I think this is a great opportunity for D to shine in this arena; typing in the override keyword is no biggie for overriding methods, given the potential two-way benefit (refactoring and inadvertent-override).
> 
> I think it should be mandated by the compiler; an overriding method without the override keyword should result in a compile time error. What say you?
> 

As I understand the issue, the current setup is that the compiler may do something that the coder is totally unaware of. There is not even an 'information' message (let's not call it a warning) to tell the coder what's going on.

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.

The general principle I have is that a computer language's primary purpose is to *help* people create correctly functioning executables. That is, the emphasis is on the "helping" role.

-- 
Derek
Melbourne, Australia

On Sun, 18 Jul 2004 06:32:15 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> I already said I want it. But I'm also a realist, and experience with D is that
> very few things which constrain the developer towards robustness and maintenance
> get in. Or am I being a cynic?

You're being a cynic. I prefer optimisim at all times, perhaps I'm just a dreamer ;o)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cdatji$17fc$1@digitaldaemon.com...
> 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/. This would be in keeping with its current meaning, and may also resolve some of the issues surrounding the need to use an alias
to
> pull in superclass methods of the same basic name (which is criminal in my opinion, but a different battle).
>
> Anyway; if override were required it would catch a number of subtle bugs
in
> derived classes. For example, I was refactoring some classes in Mango and decided to rename a couple of methods to pause() and resume() because that suited their behavior much better than the previous names. A few days
later
> I started noticing odd program-termination behaviour, and just couldn't track it down. The MSVC debugger couldn't even help me.
>
> Turns out that the class with the renamed methods was three levels removed
> from a base class of (you guessed it) ... Thread. I had inadvertently
> overridden the Thread.pause() and Thread.resume().  On win32 it didn't
cause
> a disaster, but on linux it caused segfaults during shutdown and/or thread termination. Fancy that :-)
>
> Now this is in my own library. Imagine the crap that will inevitably hit
the
> fan in a long-term maintenance scenario? I think this is a great
opportunity
> for D to shine in this arena; typing in the override keyword is no biggie for overriding methods, given the potential two-way benefit (refactoring
and
> inadvertent-override).
>
> I think it should be mandated by the compiler; an overriding method
without
> the override keyword should result in a compile time error. What say you?
>
> - Kris
>

I always use override; this sounds good to me.

"Matthew" wrote in message...
> I already said I want it. But I'm also a realist, and experience with D is
that
> very few things which constrain the developer towards robustness and
maintenance
> get in. Or am I being a cynic?

Yep; interfaces made it ~ and I was just being an arse <g>