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 my class, breaking the logical grouping of stuff
in it).
So I try that, and when I do, it complains: "Error: variable
demu.memmap.MemMap.machine final cannot be applied to variable", allegedly
a D1 remnant.
So what do I do? Another workaround? Tag everything as final individually?

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.

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, but that seems reasonable.

On Sun, 18 Mar 2012 02:23:31 +0100, Manu <turkeyman@gmail.com> 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 it's no
> good (unless I rearrange my class, breaking the logical grouping of stuff
> in it).
> So I try that, and when I do, it complains: "Error: variable
> demu.memmap.MemMap.machine final cannot be applied to variable", allegedly
> a D1 remnant.
> So what do I do? Another workaround? Tag everything as final individually?

class Foo {
    final {
        // Final functions here.
    }
    // Virtual functions here.
}

Good?


> 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.

I agree that a virtual keyword would sometimes be a boon. With the solution
outlined above, I find it a minor nit, though.

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.

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 functions I have... so it's no
> good (unless I rearrange my class, breaking the logical grouping of stuff
> in it).
> So I try that, and when I do, it complains: "Error: variable
> demu.memmap.MemMap.machine final cannot be applied to variable", allegedly
> a D1 remnant.
> So what do I do? Another workaround? Tag everything as final individually?
>
> 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.

what's so bad with:

       class Test
       {
           final {
               void nonVirtualMethod1() { ... }
               void nonVirtualMethod2() { ... }
               void nonVirtualMethod3() { ... }
               void nonVirtualMethod4() { ... }
           }

           void virtualMethod1() { ... }
           void virtualMethod2() { ... }
       }

I actually think this model makes a lot of sense because when
you're starting out with just an object concept, explicitly
specifying "these functions I don't want overridden" on the few
you're positive you don't want final is, at least to me, more
inline with how my thought process works. Optimize after the
object model is more concrete.

However, I don't think that having the option of doing it in
reverse would be a bad idea either:

       // dmd -explicitVirtual test.d

       class Test
       {
           void nonVirtualMethod1() { ... }
           void nonVirtualMethod2() { ... }
           void nonVirtualMethod3() { ... }
           void nonVirtualMethod4() { ... }

           virtual {
               void virtualMethod1() { ... }
               void virtualMethod2() { ... }
           }
       }

On 18 March 2012 03:49, Simen Kjærås <simen.kjaras@gmail.com> wrote:

> On Sun, 18 Mar 2012 02:23:31 +0100, Manu <turkeyman@gmail.com> 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 it's no
>> good (unless I rearrange my class, breaking the logical grouping of stuff
>> in it).
>> So I try that, and when I do, it complains: "Error: variable
>> demu.memmap.MemMap.machine final cannot be applied to variable", allegedly
>> a D1 remnant.
>> So what do I do? Another workaround? Tag everything as final individually?
>>
>
> class Foo {
>    final {
>        // Final functions here.
>    }
>    // Virtual functions here.
> }
>
> Good?


Ah, didn't think of braces... got stuck on the ':' approach.
That's no less ugly though, in fact, it's considerably more ugly. more
brace spam + indentation levels for nothing.


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.
>>
>
> I agree that a virtual keyword would sometimes be a boon. With the solution outlined above, I find it a minor nit, though.
>

I'm still mortified that people won't do it or just forget, and every method ever will be virtual.

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...

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
    {
        private {
            string _title;
            int _x, _y;
            // etc...
        }

        @property {
            auto title() { return _title; }
            auto x() { return _x; }
            auto y() { return _y; }
            // etc...
        }
    }

    // Or...

    struct Vector2(T)
    {
        T x, y;

        @property {
            auto xy() { return this; }
            auto yx() { return Vector2(y, x); }
        }

        @property static {
            auto zero() { return Vector2(0, 0); }
            auto one()  { return Vector2(1, 1); }
            // etc...
        }
    }

But I'm also use to C# code which is usually indented twice before you even get to functions (namespace -> class -> method).

On 18 March 2012 04:14, F i L <witte2008@gmail.com> 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 common attribute:
>
>    class Window
>    {
>        private {
>            string _title;
>            int _x, _y;
>            // etc...
>        }
>
>        @property {
>            auto title() { return _title; }
>            auto x() { return _x; }
>            auto y() { return _y; }
>            // etc...
>        }
>    }
>
>    // Or...
>
>    struct Vector2(T)
>    {
>        T x, y;
>
>        @property {
>            auto xy() { return this; }
>            auto yx() { return Vector2(y, x); }
>        }
>
>        @property static {
>            auto zero() { return Vector2(0, 0); }
>            auto one()  { return Vector2(1, 1); }
>            // etc...
>        }
>    }
>
> But I'm also use to C# code which is usually indented twice before you even get to functions (namespace -> class -> method).
>

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. There needs to be a way to declare it the
other way around without polluting my indentation levels.
final: at the top and explicit 'virtual' would make a big difference.

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 generating code, all functions that are not overridden can be optimized to be non-virtual."

So if all functions are automatically optimized to non-virtual where applicable, then the "final" keyword is for conceptual access limitation only. This makes a lot of sense to me. Is there something I'm not getting that makes you want an explicit "virtual" keyword?