virtual-by-default rant
F i L
witte2008 at gmail.com
Sat Mar 17 18:57:36 PDT 2012
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() { ... }
}
}
More information about the Digitalmars-d
mailing list