On 30.05.2012 2:27, Dmitry Olshansky wrote:

I just wish it was different. To set things straight I still believe
that OOP part of language is not what I want it to be, and thus I just
don't use it. Like in the old saying: there is always a choice.


Minor correction, when I first come to try D I used classes, I confess :). The toy project of 2D graphics engine needed resource manager, thus I used Flyweight pattern with lazy-loading/unloding behind the scenes. The concrete resource were struct on C heap but handles were small objects were derived from Resource fro obvious reasons.

Brings us back to extra word per object problem, flyweight is exactly kind of pattern that is hit by collateral damage of this decision!

OT: Actually algorithms to lazily cache resources are very similar to virtual memory management, same strategies, same action just replace "swap-out page" with "unload resource".

TL;DR all of this worked out quite well then I lost interest in the project but certainly not D itself.

Things that stopped me from using it are:
- hidden v-table design like C++ and Java, doesn't help things much.
Encapsulation is good, but if it has no advantages other then hiding
things it's bad.
- GCed by default, no provision for custom allocation until very recently
- monitor field, and who knows what else (v-table obviously, maybe
something else?)
- no tail-const, no solutions aside from rebindable and casts. Pointers
to struct look so much better in this regard ;)
- special slow built-in protocols for equality (it's robust, but I don't
need it)
- opEquals signature madness (probably fixed?)
- final vs virtual, no inlining of known ahead-of-time virtual call
- nowdays enforced purity, @safe, nothrow whatever. Why should I follow
these restrictions - dubious.

Observe that all of the above have very few advantages brought to me by
compiler:
- polymorphism
- inheritance
- contract inheritance

Of the above I only ever needed the first 2. Call me dinosaur.


Throwing in this one:
        -useless RTTi that still occupies space.
(the useless part might have been fixed recently? Some customizable field added to Typeinfo - dunno)

--
Dmitry Olshansky

Reply via email to