Disable GC entirely

[Manu]

On 10 April 2013 17:01, Paulo Pinto <pjmlp at progtools.org> wrote:

> On Wednesday, 10 April 2013 at 06:03:08 UTC, 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.
>> OOP by design recommends liberal use of accessors, ie, properties, that
>> usually just set or return a variable. Wen would you ever want @property
>> size_t size() { return size; } to be a virtual call?
>>
>
> Yes, if you want to change its behavior in a derived class.
>

That really shouldn't be encouraged. Give me an example?


One nice feature of properties is that you can trigger actions when
> assigning/reading from properties.
>

That doesn't make the property virtual, that makes the virtual that the
property calls virtual. You can't have a derived class redefining the
function of a trivial accessor. If it has a side effect that is context
specific, then it would call through to a separate virtual. And this would
be a controlled and deliberate case, ie, 1 in 100, not the norm.


This is very used in OO GUI and DB code in other languages.


I know, it's an abomination, and the main reason OOP is going out of
fashion.


Can you demonstrate a high level class, ie, not a primitive tool, but the
>> sort of thing a programmer would write in their daily work where all/most
>> functions would be virtual?
>>
>
> I have lots of code from JVM and .NET languages with such examples.
>
> OO code in the enterprise world is a beauty in itself, regardless of the
> language.
>

That's not an exampe. I want to see a class where every function SHOULD be
overloaded... That sounds like a nightmare, how can anyone other than the
author ever expect to understand it? The fewer and more deliberately
controlled the virtuals, the better, by almost every measure I can imagine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/56cd93c1/attachment-0001.html>