Disable GC entirely
Manu
turkeyman at gmail.com
Wed Apr 10 10:33:42 PDT 2013
On 11 April 2013 02:08, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:
> On 4/10/13 8:44 AM, Manu wrote:
>
>> On 10 April 2013 22:37, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130411/f4a4dfeb/attachment.html>
More information about the Digitalmars-d
mailing list