Re: virtual-by-default rant

On Saturday, 24 March 2012 at 16:27:41 UTC, Artur Skawina wrote: The question is -- are there false positives? Yes, almost certainly. This only looks at the function definition; it is run well before the optimizer.

Re: virtual-by-default rant

On 3/24/12 3:03 AM, Manu wrote: On 23 March 2012 17:24, Ary Manzana mailto:a...@esperanto.org.ar>> wrote: On 3/18/12 9:23 AM, Manu wrote: The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class". Th

Re: virtual-by-default rant

On 03/24/12 16:16, Adam D. Ruppe wrote: > On Saturday, 24 March 2012 at 10:56:27 UTC, Manu wrote: >> My objection to virtual-by-default, but, acknowledging that can't be >> changed, insistence on a virtual keyword >> is this. > > I like the idea of a virtual keyword btw. > >> Adding a system lik

Re: virtual-by-default rant

I think a better system would be to explicitly mark functions are virtual, and then use unittesting to catch virtual functions that don't need to be.

Re: virtual-by-default rant

On Saturday, 24 March 2012 at 10:56:27 UTC, Manu wrote: My objection to virtual-by-default, but, acknowledging that can't be changed, insistence on a virtual keyword is this. I like the idea of a virtual keyword btw. Adding a system like you describe to validate virtuals is not a complexity

Re: virtual-by-default rant

On Saturday, 24 March 2012 at 14:43:21 UTC, Artur Skawina wrote: It needs at least the class or method marked as 'final' to do the right thing. Indeed, that's what I'm after. I'm making another post with an implementation in reply to manu in a minute.

Re: virtual-by-default rant

On 03/23/12 20:11, Adam D. Ruppe wrote: > > http://dlang.org/traits.html#getVirtualFunctions > > if the name isn't on a list of approved virtuals, > static assert fail. And you could probably do it in a clean and unintrusive way, by, for example, extending Object, or doing it on a per-module bas

Re: virtual-by-default rant

On 23 March 2012 21:11, Adam D. Ruppe wrote: > Something that *might* help is to do unit tests. Yeah, > that's kinda ass, but it would catch a stray virtual early. > They're not necessarily 'stray' virtuals, they're inappropriate ones There's a time and place for virtuals, but there's many more

Re: virtual-by-default rant

Something that *might* help is to do unit tests. Yeah, that's kinda ass, but it would catch a stray virtual early. Do a unit test that does a traits check for virtuals: http://dlang.org/traits.html#getVirtualFunctions if the name isn't on a list of approved virtuals, static assert fail. You'd

Re: virtual-by-default rant

On 23 March 2012 17:24, Ary Manzana wrote: > On 3/18/12 9:23 AM, Manu wrote: > >> The virtual model broken. I've complained about it lots, and people >> always say "stfu, use 'final:' at the top of your class". >> >> That sounds tolerable in theory, except there's no 'virtual' keyword to >> keep

Re: virtual-by-default rant

On 3/18/12 9:23 AM, Manu wrote: The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class". That sounds tolerable in theory, except there's no 'virtual' keyword to keep the virtual-ness of those 1-2 virtual functions I have... so

Re: virtual-by-default rant

Given that the four most popular languages today (Java, C, C++, and C#) all function this way, I'd say it's fairly accurate. But I also didn't to say Final by default should be default in D (though I wouldn't really disagree with that direction either), I do think D should have a virtual keywor

Re: virtual-by-default rant

On Friday, 23 March 2012 at 13:58:00 UTC, Timon Gehr wrote: On 03/23/2012 02:47 PM, F i L wrote: ... and most programmers are already used to fixed by default anyways. This assertion is unjustified. Given that the four most popular languages today (Java, C, C++, and C#) all function this

Re: virtual-by-default rant

On 03/23/2012 02:47 PM, F i L wrote: ... and most programmers are already used to fixed by default anyways. This assertion is unjustified.

Re: virtual-by-default rant

Marco Leise wrote: "the D compiler knows all of the class hierarchy when generating code" This is just wrong, and if that was the base for deciding on virtual as default, I believe it is natural to think about it again. Yes, further reading has led me to believe that Manu is right in his req

Re: virtual-by-default rant

Am Sun, 18 Mar 2012 04:49:12 +0100 schrieb "F i L" : > On Sunday, 18 March 2012 at 03:27:40 UTC, bearophile wrote: > > F i L: > > > >> I'm a bit confused. Reading through the virtual function's > >> docs (http://dlang.org/function.html#virtual-functions) it > >> says: > >> > >> "All non-static

Re: virtual-by-default rant

Le 18/03/2012 22:36, James Miller a écrit : On 19 March 2012 06:41, David Nadlinger wrote: On Sunday, 18 March 2012 at 17:24:15 UTC, F i L wrote: […] I know LDC has a LTO flag. Unfortunately it doesn't (-O4/-O5 are defunct), but working on seamless LTO integration (and better optimization

Re: virtual-by-default rant

On 19.03.2012 14:45, Artur Skawina wrote: On 03/19/12 08:30, Dmitry Olshansky wrote: On 19.03.2012 2:17, Artur Skawina wrote: On 03/18/12 15:37, Dmitry Olshansky wrote: On 18.03.2012 5:23, Manu wrote: The virtual model broken. I've complained about it lots, and people always say "stfu, use 'f

Re: virtual-by-default rant

On 03/19/12 08:30, Dmitry Olshansky wrote: > On 19.03.2012 2:17, Artur Skawina wrote: >> On 03/18/12 15:37, Dmitry Olshansky wrote: >>> On 18.03.2012 5:23, Manu wrote: The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your cla

Re: virtual-by-default rant

On 19.03.2012 2:17, Artur Skawina wrote: On 03/18/12 15:37, Dmitry Olshansky wrote: On 18.03.2012 5:23, Manu wrote: The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class". That sounds tolerable in theory, except there's no '

Re: virtual-by-default rant

On 03/18/12 15:37, Dmitry Olshansky wrote: > On 18.03.2012 5:23, Manu wrote: >> The virtual model broken. I've complained about it lots, and people >> always say "stfu, use 'final:' at the top of your class". >> >> That sounds tolerable in theory, except there's no 'virtual' keyword to >> keep the

Re: virtual-by-default rant

On 19 March 2012 06:41, David Nadlinger wrote: > On Sunday, 18 March 2012 at 17:24:15 UTC, F i L wrote: >> >> […] I know LDC has a  LTO flag. > > > Unfortunately it doesn't (-O4/-O5 are defunct), but working on seamless LTO > integration (and better optimization pass scheduling in general) would b

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 17:24:15 UTC, F i L wrote: […] I know LDC has a LTO flag. Unfortunately it doesn't (-O4/-O5 are defunct), but working on seamless LTO integration (and better optimization pass scheduling in general) would be low-hanging fruit for anybody wanting to join LDC devel

Re: virtual-by-default rant

David Nadlinger wrote: Which is wrong as long as you don't do link-time optimization, and DMD probably won't in the foreseeable future. Are GDC and LDC limited by DMD in this regard? I know LDC has a LTO flag. If GDC/LDC supports LTO and/or DMD will in the eventual future, then I think defa

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 16:02:04 UTC, Martin Nowak wrote: Is this even possible without LTO/WPO? Extending a class defined in a library you link in (and for which codegen already happened) is certainly possible… David This is not even possible with LTO because new classes could be loaded

Re: virtual-by-default rant

Le 18/03/2012 17:02, Martin Nowak a écrit : This is so much theoretical that I think this should be removed from the D docs. And to be put back when one DMD compiler is able to do this. Otherwise it's just false advertising :-) Is this even possible without LTO/WPO? Extending a class defined in

Re: virtual-by-default rant

This is so much theoretical that I think this should be removed from the D docs. And to be put back when one DMD compiler is able to do this. Otherwise it's just false advertising :-) Is this even possible without LTO/WPO? Extending a class defined in a library you link in (and for which co

Re: virtual-by-default rant

Le 18/03/2012 16:26, Andrei Alexandrescu a écrit : On 3/18/12 8:39 AM, deadalnix wrote: It just show the need of keyword to express the opposite of final, virtual. The same problem occur with const immutable, you cannot go back to the mutable world when you use « const: » for example. Yah, ~co

Re: virtual-by-default rant

On 3/18/12 8:39 AM, deadalnix wrote: It just show the need of keyword to express the opposite of final, virtual. The same problem occur with const immutable, you cannot go back to the mutable world when you use « const: » for example. Yah, ~const etc. have been suggested a couple of times. Help

Re: virtual-by-default rant

On 3/18/12 6:59 AM, F i L wrote: Manu wrote: D knows nothing about the class hierarchy when generating code, I don't know how it can make that claim? How does D not know about class hierarchy when generating code? That doesn't make sense to me. It *has* to know to even generate code. It know

Re: virtual-by-default rant

On 3/18/12 6:37 AM, Manu wrote: On 18 March 2012 06:42, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>> wrote: Then probably struct is what you're looking for. No, I definitely want a class. ref type, gc mem, etc. struct doesn't support virtual at all. I have 2 virtuals, this par

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 14:46:55 UTC, David Nadlinger wrote: On Sunday, 18 March 2012 at 14:27:04 UTC, David Nadlinger wrote: Which is wrong as long as you don't do link-time optimization, and DMD probably won't in the foreseeable future. I tried to explain that above, think extending Threa

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 14:27:04 UTC, David Nadlinger wrote: Which is wrong as long as you don't do link-time optimization, and DMD probably won't in the foreseeable future. I tried to explain that above, think extending Thread, which has already been compiled into druntime, from your appli

Re: virtual-by-default rant

On 18.03.2012 5:23, Manu wrote: The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class". That sounds tolerable in theory, except there's no 'virtual' keyword to keep the virtual-ness of those 1-2 virtual functions I have... so

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 13:54:20 UTC, F i L wrote: […] I think you're assuming the compiler can't, in good faith, optimize out virtual functions. Whereas I'm assuming it can. Which is wrong as long as you don't do link-time optimization, and DMD probably won't in the foreseeable future. I

Re: virtual-by-default rant

Manu wrote: I mean it can't possibly know the complete 'final' class hierarchy, ie, the big picture. Anything anywhere could extend it. The codegen must assume such. I still don't understand why you think this. The compiler must understand the full hierarchy it's compiling, and like I said

Re: virtual-by-default rant

Le 18/03/2012 03:47, F i L a écrit : I'm a bit confused. Reading through the virtual function's docs (http://dlang.org/function.html#virtual-functions) it says: "All non-static non-private non-template member functions are virtual. This may sound inefficient, but since the D compiler knows all o

Re: virtual-by-default rant

Le 18/03/2012 02:23, Manu a écrit : The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class". That sounds tolerable in theory, except there's no 'virtual' keyword to keep the virtual-ness of those 1-2 virtual functions I have...

Re: virtual-by-default rant

On 18 March 2012 13:59, F i L wrote: > Manu wrote: > >> D knows nothing about the class hierarchy when generating code, I don't >> know how it can make that claim? >> > > How does D not know about class hierarchy when generating code? That > doesn't make sense to me. It *has* to know to even gene

Re: virtual-by-default rant

On 2012-03-18 04:27, bearophile wrote: F i L: I'm a bit confused. Reading through the virtual function's docs (http://dlang.org/function.html#virtual-functions) it says: "All non-static non-private non-template member functions are virtual. This may sound inefficient, but since the D compiler

Re: virtual-by-default rant

Manu wrote: D knows nothing about the class hierarchy when generating code, I don't know how it can make that claim? How does D not know about class hierarchy when generating code? That doesn't make sense to me. It *has* to know to even generate code. Anything that's not private can be ext

Re: virtual-by-default rant

On 18 March 2012 06:42, Andrei Alexandrescu wrote: > On 3/17/12 9:24 PM, Manu wrote: > >> Yeah, I'm not really into that. I group things conceptually. >> Either way, I've never written a class where non-virtuals don't outweigh >> virtuals in the realm of 20:1. >> > > Then probably struct is what

Re: virtual-by-default rant

On 18 March 2012 04:47, F i L wrote: > I'm a bit confused. Reading through the virtual function's docs ( > http://dlang.org/function.**html#virtual-functions) > it says: > > "All non-static non-private non-template member functions are virtual. >

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 03:27:40 UTC, bearophile wrote: F i L: "All non-static non-private non-template member functions are virtual. This may sound inefficient, but since the D compiler knows all of the class hierarchy when generating code, all functions that are not overridden can be opt

Re: virtual-by-default rant

On 3/18/2012 12:27 PM, bearophile wrote: F i L: I'm a bit confused. Reading through the virtual function's docs (http://dlang.org/function.html#virtual-functions) it says: "All non-static non-private non-template member functions are virtual. This may sound inefficient, but since the D compile

Re: virtual-by-default rant

On 3/17/12 9:24 PM, Manu wrote: Yeah, I'm not really into that. I group things conceptually. Either way, I've never written a class where non-virtuals don't outweigh virtuals in the realm of 20:1. Then probably struct is what you're looking for. Andrei

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 03:27:40 UTC, bearophile wrote: F i L: I'm a bit confused. Reading through the virtual function's docs (http://dlang.org/function.html#virtual-functions) it says: "All non-static non-private non-template member functions are virtual. This may sound inefficient, b

Re: virtual-by-default rant

F i L: > I'm a bit confused. Reading through the virtual function's docs > (http://dlang.org/function.html#virtual-functions) it says: > > "All non-static non-private non-template member functions are > virtual. This may sound inefficient, but since the D compiler > knows all of the class hier

Re: virtual-by-default rant

I'm a bit confused. Reading through the virtual function's docs (http://dlang.org/function.html#virtual-functions) it says: "All non-static non-private non-template member functions are virtual. This may sound inefficient, but since the D compiler knows all of the class hierarchy when generati

Re: virtual-by-default rant

On 18 March 2012 04:14, F i L wrote: > Manu wrote: > >> That's no less ugly though, in fact, it's considerably more ugly. more >> brace spam + indentation levels for nothing. >> > > I actually like the bracket+indentation as a section separator indicator. > Usually I'll "group" fields/methods by

Re: virtual-by-default rant

Manu wrote: That's no less ugly though, in fact, it's considerably more ugly. more brace spam + indentation levels for nothing. I actually like the bracket+indentation as a section separator indicator. Usually I'll "group" fields/methods by common attribute: class Window {

Re: virtual-by-default rant

F i L wrote: specifying "these functions I don't want overridden" on the few you're positive you don't want final is... **you're positive you *DO* want final is...

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 01:23:42 UTC, Manu wrote: The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class". That sounds tolerable in theory, except there's no 'virtual' keyword to keep the virtual-ness of those 1-2 virtual

Re: virtual-by-default rant

On 18 March 2012 03:49, Simen Kjærås wrote: > On Sun, 18 Mar 2012 02:23:31 +0100, Manu wrote: > > The virtual model broken. I've complained about it lots, and people always >> say "stfu, use 'final:' at the top of your class". >> >> That sounds tolerable in theory, except there's no 'virtual' k

Re: virtual-by-default rant

On 3/17/2012 6:23 PM, Manu wrote: Tag everything as final individually? You can use: final { ... all the final members ... } instead of individual tags.

Re: virtual-by-default rant

On Sunday, 18 March 2012 at 01:23:42 UTC, Manu wrote: My minimum recommendation: D needs an explicit 'virtual' keyword, and to fix that D1 bug, so putting final: at the top of your class works, and everything from there works as it should. Agreed. Final by default is a proposition long gone,

Re: virtual-by-default rant

On Sun, 18 Mar 2012 02:23:31 +0100, Manu wrote: The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class". That sounds tolerable in theory, except there's no 'virtual' keyword to keep the virtual-ness of those 1-2 virtual fun

virtual-by-default rant

The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class". That sounds tolerable in theory, except there's no 'virtual' keyword to keep the virtual-ness of those 1-2 virtual functions I have... so it's no good (unless I rearrange m