On 11 April 2013 02:08, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
On 4/10/13 8:44 AM, Manu wrote:
On 10 April 2013 22:37, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>

wrote:

    On 4/10/13 2:02 AM, Manu wrote:

        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.


    I'd say a valid style is to use free functions for non-virtual
    methods. UFCS will take care of caller syntax.


Valid, perhaps. But would you really recommend that design pattern?
It seems a little obscure for no real reason. Breaks the feeling of the
OO encapsulation principle somewhat.

It may as well be a mistake that nonvirtual functions are at all part of a class' methods. This has been quite painfully seen in C++ leading to surprising conclusions: http://goo.gl/dqZrr.

Hmm, some interesting points. Although I don't think I buy what he's selling.
It looks like over-complexity for the sake of it to me. I don't buy the real-world benefit. At least not more so than the obscurity it introduces (breaking the location of function definitions apart), and of course, C++ doesn't actually support this syntactically, it needs UFCS.
Granted, the principle applies far better to D, ie, actually works...


If I designed D's classes today, I'd only allow overridable methods and leave everything else to free functions.

Why? Sorry, that article didn't sell me. Maybe I need to sit and simmer on it for a bit longer though. I like static methods (I prefer them to virtuals!) ;)
If I had the methods spit, some inside the class at one indentation level, and most outside at a different level, it would annoy me, for OCD reasons. But I see no real advantage one way or the other in D, other than a cosmetic one.