<div dir="ltr">On 10 April 2013 15:08, Rob T <span dir="ltr"><<a href="mailto:alanb@ucora.com" target="_blank">alanb@ucora.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wednesday, 10 April 2013 at 04:32:52 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
final on the class means you can't derive it anymore (what's the point of a<br>
class?),<br>
</blockquote>
<br></div>
I think that you'd place final on a derived class, not a base class. So it can make perfect sense, although final on the methods of a final class makes little sense so it should probably be a compiler error.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and the manual final blocks are totally prone to error.<br>
In my experience, 90% of functions are not (or rather, should not be)<br>
virtual. The common (and well performing) case should be default.<br>
</blockquote>
<br></div>
Believe it or not, but I actually have been in the reverse position more than once, so which way the default should go is debatable. In your case I can certainly see why you'd prefer the opposite as I've done RT programming before and will be doing it again. What could perhaps work is a module level specifier that indicates what the defaults should be as a matter of use case preference, but I can see that going horribly wrong.<br>

<br>
The question I have, is why use a class if you do not need to use virtual functions? I think the problem goes a bit deeper than the defaults being opposite of what you want. I expect that you'd probably want struct inheritance or something like that but cannot get it from D?</blockquote>
<div><br></div><div style>I do use virtual functions, that's the point of classes. But most functions are not virtual. More-so, most functions are trivial accessors, which really shouldn't be virtual.</div><div style>
OOP by design recommends liberal use of accessors, ie, properties, that usually just set or return a variable. Wen would you ever want @property size_t size() { return size; } to be a virtual call?</div><div style><br></div>
<div style>A base class typically offers a sort of template of something, implementing as much shared/common functionality as possible, but which you might extend, or make more specific in some very controlled way.</div><div style>
Typically the base functionality and associated accessors deal with variable data contained in the base-class.</div><div style><br></div><div style>The only situations I can imagine where most functions would be virtual are either a) ridiculously small classes with only 2 functions (at least you'll only type 'virtual' once or twice in this case), b) some sort of OOP-tastic widget that 'can do anything!' or tries to be a generalisation of an 'anything', which is, frankly, horrible and immature software design, and basically the entire reason OOP is developing a name as being a terrible design pattern in the first place...</div>
<div style>I wouldn't make the latter case an implicit recommendation through core language design... but apparently that's just me ;)</div><div style><br></div><div style>No I don't want struct inheritance (although that would be nice! but I'm okay with aggregating and 'alias this'), that would insist on using 'ref' everywhere, and you can't create ref locals, so you can't really use structs conveniently this way.</div>
<div style>Classes are reference types, that's the point. I know what a class is, and I'm happy with all aspects of the existing design, except this one thing.</div><div><br></div><div style>Can you demonstrate a high level class, ie, not a primitive tool, but the sort of thing a programmer would write in their daily work where all/most functions would be virtual?</div>
<div style>I can paste almost any class I've ever written, there is usually 2-4 virtuals, among 20-30 functions.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any language with properties can't have virtual-by-default.<br>
Seriously, .length or any other trivial property that can no longer be<br>
inlined, or even just called.<br>
And human error aside, do you really want to have to type final on every<br>
function? Or indent every line an extra tab level?<br>
</blockquote>
<br></div>
Mark your properties as final?<br></blockquote><div><br></div><div style>That's 90% of the class! You are familiar with OOP right? :)</div><div style>Almost everything is an accessor...</div><div><br></div><div style>
I usually have 2 virtual functions, update() and draw(), or perhaps there's a purpose specific doWork() type of function to perform the derived object's designated function, but basically everything else is trivial accessors, or base class concepts that make absolutely no sense to override.</div>
<div style>I also work with lots of C++ middleware, and the virtuals are usually tightly controlled and deliberately minimised, and there's a good reason for this too; the fewer virtuals that the user is expected to override, the simpler it is to understand and work with your class!</div>
<div style>Additionally, it's a nice self-documenting feature; at a glance you can see the virtuals, ie, what you need to do to make use of a 3rd party OOP API.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

[...]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't want to ban the use of virtual functions. I want to ban the use of<div class="im"><br>
virtual functions that aren't marked virtual explicitly! ;)<br>
<br>
Likewise, I like the GC, I just want to be able to control it.<br>
Disable auto-collect, explicitly issue collect calls myself at controlled<br>
moments, and give the collect function a maximum timeout where it will<br>
yield, and then resume where it left off next time I call it.<br>
</div></blockquote>
<br>
I agree 100% and have that need too. I'd go further and also prefer the ability to optionally ban certain language features from use from within selective parts of my code base. As you say, I do not actually want to outright ban the GC or any other language feature (I really do use them!!!), it's only the desire to be able to have much better control over it for the situations that demand precision and certainty.<br>
</blockquote><div><br></div><div style>Precisely.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having control over D and the GC like what we're taking about in here can turn D into a seriously awesome systems language unlike any other.</blockquote><div><br></div><div style>Correct, it's not quite a systems language while the GC does whatever it wants. But D needs the GC to be considered a 'modern', and generally productive language.</div>
</div></div></div>