www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What's about virtual?

reply "Namespace" <rswhite4 googlemail.com> writes:
It's been a while since Manu convinced Walter and Andrei to 
introduce a virtual Keyword and to change the default from 
virtual methods to final methods.
Anything new? Anybody working on that? I would love to see that 
soon.
Sep 09 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
 It's been a while since Manu convinced Walter and Andrei to
 introduce a virtual Keyword and to change the default from virtual
 methods to final methods.
 Anything new? Anybody working on that? I would love to see that
 soon.
This is going to break a lot of code. We'd need some kind of deprecation path. And even then, it may anger a lot of existing users. T -- Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!
Sep 09 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 9 September 2013 at 19:48:50 UTC, H. S. Teoh wrote:
 On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
 It's been a while since Manu convinced Walter and Andrei to
 introduce a virtual Keyword and to change the default from 
 virtual
 methods to final methods.
 Anything new? Anybody working on that? I would love to see that
 soon.
This is going to break a lot of code. We'd need some kind of deprecation path. And even then, it may anger a lot of existing users. T
Even if it would break code, the introducing of the virtual keyword could be done without. The change of virtual by default -> final by default could be done after the introducing.
Sep 09 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/9/13 12:47 PM, H. S. Teoh wrote:
 On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
 It's been a while since Manu convinced Walter and Andrei to
 introduce a virtual Keyword and to change the default from virtual
 methods to final methods.
 Anything new? Anybody working on that? I would love to see that
 soon.
This is going to break a lot of code. We'd need some kind of deprecation path. And even then, it may anger a lot of existing users. T
After I've seen a pretty cool demo of clang-modernize (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way to attack this and similar problems is to add a class hierarchy analyzer: a command-line utility that is fed an entire project and adds as many 'final' as possible without changing semantics. Time has come to migrate such functionality to tools. We keep on telling that "nobody uses the tools" but it seems experience contradicts that belief. Andrei
Sep 09 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 09, 2013 at 05:28:24PM -0700, Andrei Alexandrescu wrote:
 On 9/9/13 12:47 PM, H. S. Teoh wrote:
On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
It's been a while since Manu convinced Walter and Andrei to
introduce a virtual Keyword and to change the default from virtual
methods to final methods.  Anything new? Anybody working on that? I
would love to see that soon.
This is going to break a lot of code. We'd need some kind of deprecation path. And even then, it may anger a lot of existing users.
[...]
 After I've seen a pretty cool demo of clang-modernize
 (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best
 way to attack this and similar problems is to add a class hierarchy
 analyzer: a command-line utility that is fed an entire project and
 adds as many 'final' as possible without changing semantics.
 
 Time has come to migrate such functionality to tools. We keep on
 telling that "nobody uses the tools" but it seems experience
 contradicts that belief.
[...] This would also be a good use case to motivate a reusable lexer/parser (e.g., std.d.lexer that has been suggested for review). T -- Some days you win; most days you lose.
Sep 09 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-10 02:28, Andrei Alexandrescu wrote:

 After I've seen a pretty cool demo of clang-modernize
 (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way
 to attack this and similar problems is to add a class hierarchy
 analyzer: a command-line utility that is fed an entire project and adds
 as many 'final' as possible without changing semantics.

 Time has come to migrate such functionality to tools. We keep on telling
 that "nobody uses the tools" but it seems experience contradicts that
 belief.
I completely agree. But then again, we need a D front end for this. -- /Jacob Carlborg
Sep 10 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Tuesday, 10 September 2013 at 00:28:24 UTC, Andrei 
Alexandrescu wrote:
 On 9/9/13 12:47 PM, H. S. Teoh wrote:
 On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
 It's been a while since Manu convinced Walter and Andrei to
 introduce a virtual Keyword and to change the default from 
 virtual
 methods to final methods.
 Anything new? Anybody working on that? I would love to see 
 that
 soon.
This is going to break a lot of code. We'd need some kind of deprecation path. And even then, it may anger a lot of existing users. T
After I've seen a pretty cool demo of clang-modernize (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way to attack this and similar problems is to add a class hierarchy analyzer: a command-line utility that is fed an entire project and adds as many 'final' as possible without changing semantics. Time has come to migrate such functionality to tools. We keep on telling that "nobody uses the tools" but it seems experience contradicts that belief. Andrei
Does it mean that we have to delay the change (virtual by default -> final by default) somewhat, but still introduce the virtual keyword? Or does it mean that nothing is introduced and everything stays as it is?
Sep 10 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 10 Sep 2013 02:28:24 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 9/9/13 12:47 PM, H. S. Teoh wrote:
 On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
 It's been a while since Manu convinced Walter and Andrei to
 introduce a virtual Keyword and to change the default from virtual
 methods to final methods.
 Anything new? Anybody working on that? I would love to see that
 soon.
This is going to break a lot of code. We'd need some kind of deprecation path. And even then, it may anger a lot of existing users. T
After I've seen a pretty cool demo of clang-modernize (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way to attack this and similar problems is to add a class hierarchy analyzer: a command-line utility that is fed an entire project and adds as many 'final' as possible without changing semantics. Time has come to migrate such functionality to tools. We keep on telling that "nobody uses the tools" but it seems experience contradicts that belief.
So the catastrophe that is virtual by default will not be changed? -- Simen
Sep 10 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, September 10, 2013 11:27:40 Simen Kjaeraas wrote:
 On Tue, 10 Sep 2013 02:28:24 +0200, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:
 On 9/9/13 12:47 PM, H. S. Teoh wrote:
 On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
 It's been a while since Manu convinced Walter and Andrei to
 introduce a virtual Keyword and to change the default from virtual
 methods to final methods.
 Anything new? Anybody working on that? I would love to see that
 soon.
This is going to break a lot of code. We'd need some kind of deprecation path. And even then, it may anger a lot of existing users. T
After I've seen a pretty cool demo of clang-modernize (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way to attack this and similar problems is to add a class hierarchy analyzer: a command-line utility that is fed an entire project and adds as many 'final' as possible without changing semantics. Time has come to migrate such functionality to tools. We keep on telling that "nobody uses the tools" but it seems experience contradicts that belief.
So the catastrophe that is virtual by default will not be changed?
AFAIK, no official decision has ever been made. It seemed like Walter was convinced that it was worth it to make non-virtual the default, and some discussion went into how to do the transition, but I don't believe that Andrei has ever liked the idea, and Walter never said that it was definitively happening, much as he seemed to have been convinced that it should happen. And no one has implemented a pull request for it, so nothing has happened. So AFAIK, it could go either way at this point. We should probably create a DIP for it and discuss it. I've been meaning to do that but have been quite busy lately and haven't gotten around to it. - Jonathan M Davis
Sep 10 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 On Tuesday, 10 September 2013 at 09:32:58 UTC, Jonathan M Davis 
 wrote:
 AFAIK, no official decision has ever been made. It seemed like 
 Walter was
 convinced that it was worth it to make non-virtual the default, 
 and some
 discussion went into how to do the transition, but I don't 
 believe that Andrei
 has ever liked the idea, and Walter never said that it was 
 definitively
 happening, much as he seemed to have been convinced that it 
 should happen. And
 no one has implemented a pull request for it, so nothing has 
 happened. So
 AFAIK, it could go either way at this point. We should probably 
 create a DIP
 for it and discuss it. I've been meaning to do that but have 
 been quite busy
 lately and haven't gotten around to it.

 - Jonathan M Davis
Anyway, the introducing of the virtual keyword could be useful, even without the change. With that, we could interrupt final labes. I use mostly: ---- final: // final methods ---- but it would be nice if I don't have to put all virtual methods above the label. With virtual I could do it this way: ---- final: // final methods virtual: // virtual methods ---- That's a huge comfort.
Sep 10 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
Another idea:
Currently the protection labels, like public, private etc. , can 
be restored. But other modifier, like const, nothrow,  safe or, 
in this case, final can't. I suggest to change this. We could use 
default for that purpose. Default could interrupt all modifier 
labels and would restore the default behaviour.
Sep 10 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/10/2013 02:28 AM, Andrei Alexandrescu wrote:
 ...

 After I've seen a pretty cool demo of clang-modernize
 (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way
 to attack this and similar problems is to add a class hierarchy
 analyzer: a command-line utility that is fed an entire project and adds
 as many 'final' as possible without changing semantics.

 Time has come to migrate such functionality to tools. We keep on telling
 that "nobody uses the tools" but it seems experience contradicts that
 belief.


 Andrei
This is of course a valid possibility, but if this kind of tooling is available, making the change becomes a rather trivial issue in the first place, since old code can just be fixed up automatically.
Sep 10 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/10/2013 01:46 PM, Timon Gehr wrote:
 On 09/10/2013 02:28 AM, Andrei Alexandrescu wrote:
 ...

 After I've seen a pretty cool demo of clang-modernize
 (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way
 to attack this and similar problems is to add a class hierarchy
 analyzer: a command-line utility that is fed an entire project and adds
 as many 'final' as possible without changing semantics.

 Time has come to migrate such functionality to tools. We keep on telling
 that "nobody uses the tools" but it seems experience contradicts that
 belief.


 Andrei
This is of course a valid possibility, but if this kind of tooling is available, making the change becomes a rather trivial issue in the first place, since old code can just be fixed up automatically.
(None of this is closely related to the OT though.)
Sep 10 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/09/13 11:32, Jonathan M Davis wrote:
 AFAIK, no official decision has ever been made. It seemed like Walter was
 convinced that it was worth it to make non-virtual the default, and some
 discussion went into how to do the transition, but I don't believe that Andrei
 has ever liked the idea, and Walter never said that it was definitively
 happening, much as he seemed to have been convinced that it should happen.
I seem to recall that the killer argument consisted of 2 parts: * Having final-by-default means having speed by default. If people's default experience is slower than C++, they will not hang around to work out why or discover that speedups are possible. * With final by default, a missing "virtual" on a method can be corrected without breaking downstream code. By contrast, with virtual by default, a missing "final" on a method (or whole class) can't be corrected without a risk of downstream breakage. The second was the one that really sold it to me.
Sep 10 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 And even then, it may anger a lot of existing users.
I'm not sure about that. It seems people who actually write class-based code would prefer to have this (that's my limited analysis of IRC comments :p).
Sep 09 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 9 September 2013 at 19:52:34 UTC, Andrej Mitrovic 
wrote:
 On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 And even then, it may anger a lot of existing users.
I'm not sure about that. It seems people who actually write class-based code would prefer to have this (that's my limited analysis of IRC comments :p).
So then: what's the matter? When does it starts? ;) It is much more important than those unnecessary DIP's like 47 / 48.
Sep 09 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 09, 2013 at 09:52:21PM +0200, Andrej Mitrovic wrote:
 On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 And even then, it may anger a lot of existing users.
I'm not sure about that. It seems people who actually write class-based code would prefer to have this (that's my limited analysis of IRC comments :p).
Well, then I stand corrected. :) T -- What do you get if you drop a piano down a mineshaft? A flat minor.
Sep 09 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 Well, then I stand corrected. :)
You may sit. You get a D.
Sep 09 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 09, 2013 at 10:05:18PM +0200, Andrej Mitrovic wrote:
 On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 Well, then I stand corrected. :)
You may sit. You get a D.
Just what I needed: another D in programming. :-P T -- A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth
Sep 09 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, September 10, 2013 18:53:32 Joseph Rushton Wakeling wrote:
 On 10/09/13 11:32, Jonathan M Davis wrote:
 AFAIK, no official decision has ever been made. It seemed like Walter was
 convinced that it was worth it to make non-virtual the default, and some
 discussion went into how to do the transition, but I don't believe that
 Andrei has ever liked the idea, and Walter never said that it was
 definitively happening, much as he seemed to have been convinced that it
 should happen.
I seem to recall that the killer argument consisted of 2 parts: * Having final-by-default means having speed by default. If people's default experience is slower than C++, they will not hang around to work out why or discover that speedups are possible. * With final by default, a missing "virtual" on a method can be corrected without breaking downstream code. By contrast, with virtual by default, a missing "final" on a method (or whole class) can't be corrected without a risk of downstream breakage. The second was the one that really sold it to me.
What seemed to have convinced Walter was this interview http://www.artima.com/intv/nonvirtualP.html where the focus was on code maintainability and how C#'s approach to virtuality supported code versioning. However, most of the rest of the discussion and what most everyone else was looking for had to do with speed by default. - Jonathan M Davis
Sep 10 2013
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 10 September 2013 at 18:42:16 UTC, Jonathan M Davis 
wrote:
 What seemed to have convinced Walter was this interview

 http://www.artima.com/intv/nonvirtualP.html

 where the focus was on code maintainability and how C#'s 
 approach to
 virtuality supported code versioning. However, most of the rest 
 of the
 discussion and what most everyone else was looking for had to 
 do with speed by
 default.
Yes, and the core of the case made in that interview was the second of the arguments I cited, though in the interview it was made in more detail and more carefully argued.
Sep 10 2013