<div dir="ltr">On 10 April 2013 19:44, Regan Heath <span dir="ltr"><<a href="mailto:regan@netmail.co.nz" target="_blank">regan@netmail.co.nz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Wed, 10 Apr 2013 09:56:01 +0100, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On 10 April 2013 17:01, Paulo Pinto <<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a>> wrote:<br>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
[...]<br>
<br>
<br>
I do use virtual functions, that's the point of classes. But most<br>
functions<br>
are not virtual. More-so, most functions are trivial accessors, which<br>
really shouldn't be virtual.<br>
OOP by design recommends liberal use of accessors, ie, properties, that<br>
usually just set or return a variable. Wen would you ever want @property<br>
size_t size() { return size; } to be a virtual call?<br>
<br>
</blockquote>
<br>
Yes, if you want to change its behavior in a derived class.<br>
<br>
</blockquote>
<br></div><div class="im">
That really shouldn't be encouraged. Give me an example?<br>
</div></blockquote>
<br>
I wrote some crypto code which had a property for the hash size, each derived class returned it's own size.  Now, in this case the property size() was called rarely, but it's still a valid example.<br></blockquote>
<div><br></div><div style>But this is a trivial class, with 2 methods, size() and computeHash(). It's also a primitive tool that should probably live in a standard library. It's not the sort of code people are writing on a daily basis.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That said, I agree we don't generally want properties and other short-and-should-be-inlined methods to be virtual by default.  But.. is D really doing that?  I mean /actually/ really doing it.<br></blockquote><div><br>
</div><div style>Yes. People don't write final on everything. It's not a habit, and it's not even recommended anywhere.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

I have read most of this thread in passing and I've seen the earlier discussion about classes in libraries etc and TBH I am not sure how/what D does in those situations.  Presumably if D does not have the source for the library then the library class would have to have all methods virtual - just in case it was derived from and I guess this is an issue that needs solving somehow.  But, I don't know if this is the case, or if this is even an actual problem.<br>
</blockquote><div><br></div><div style>It's a problem. And I don't believe it's 'solvable'.</div><div style>The only solution I can imagine is to not force the compiler into that completely unknowable situation in the first place, by making virtual explicit to begin with.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That's not the most common case however, the common case is a class you're compiling with the rest of your classes and in this case D is not going to make your base class methods (which have not explicitly been overridden) virtual, they should be non-virtual and optimised/inlined/etc.  They just start out "virtually" virtual until the compiler is finished compiling them and all derived classes, at that point all non-override base methods should be non-virtual.<br>
</blockquote><div><br></div><div style>I don't see how this is possible, unless the instance was created in the same local scope, and that's extremely unlikely.</div><div style>Even if it has the source for my class, it can't ever know that the pointer I hold is not a base to a more derived class. It could be returned from a DLL or anything.</div>
<div style>Everyone keeps talking like this is possible. Is it? I can't imagine any way that it is.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

It would be interesting to see what the compiler actually does if, for example, you compile a file with a class then in a separate compile/link step compile a derived class and link.  Does D manage to non-virtual all non-overridden methods?  If so, can it do the same with a lib/dll combo?</blockquote>
<div><br></div><div style>The compiler makes a virtual call. If a static lib, or a DLL is involved, I don't see how the optimisation could ever be valid?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That's not an exampe. I want to see a class where every function SHOULD be<br>
overloaded... That sounds like a nightmare, how can anyone other than the<br>
author ever expect to understand it? The fewer and more deliberately<br>
controlled the virtuals, the better, by almost every measure I can imagine.<br>
</blockquote>
<br></div>
This isn't the reasoning behind making virtual the virtual default for methods.  The reason for doing it was simply so the compiler could be responsible for figuring it out without you having to label it manually.</blockquote>
<div><br></div><div>Yes but the compiler can't figure it out. It's not logically possible, it must always assume that it could potentially be derived somewhere... because it could.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  You're already labelling the derived class method "override" and that should be enough.  This was a choice of convenience and ultimately performance because you won't accidentally make a method virtual that doesn't need to be.</blockquote>
<div><br></div><div style>Sorry, I don't follow. How does this help?</div></div></div></div>