On 3 June 2013 02:37, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

On 6/2/13 9:59 AM, Manu wrote:

I've never said that virtuals are bad. The key function of a class is
polymorphism.
But the reality is that in non-tool or container/foundational classes
(which are typically write-once, use-lots; you don't tend to write these
daily), a typical class will have a couple of virtuals, and a whole
bunch of properties.

I've argued if no dispatch is needed just make those free functions.

You're not going to win many friends, and probably not many potential D users by insisting people completely change their coding patterns that they've probably held for decades on a trivial matter like this.

And if that's to be realistic, there are some problems that need to be addressed with that. The template issue for a start.

_Everything_ in a class is supposed to be overridable, unless inherited and explicitly "final"ized.

Who says? I certainly wouldn't say that. Sounds like a horrible idea to me.

C++ and C# users would never say that.

It sounds like a disaster waiting to happen to me. There are functions that the author intended to be overridden, and functions that have no business being overridden, that the author probably never imagined anyone would override.

What if someone does come along and override one of these, and it was never designed to work under that circumstance in the first place?

At very least, it will have never been tested. That's not a very robust API offering if you ask me.

It's sort of a historical accident that things got the way they are. But in D we know better because we have the module-level privacy model and UFCS. So we should break clean from history.

Why? Can you actually justify what's bad about a class containing it's properties/accessors? (I've read the article you pointed me at once, it was interesting, but didn't convince me)

Interestingly, you didn't actually disagree with my point about the common case here, and I don't buy the Java doctrine.