On 11 April 2013 02:08, Andrei Alexandrescu <[email protected]>wrote:
> On 4/10/13 8:44 AM, Manu wrote: > >> On 10 April 2013 22:37, Andrei Alexandrescu >> <[email protected] >> <mailto:SeeWebsiteForEmail@**erdani.org<[email protected]> >> >> >> >> 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.
