On 30.05.2012 1:48, Andrei Alexandrescu wrote:

I know. If anything it's hardly a good excuse, it should have been
revisited once TLS was introduced. It still can be now.

Don't be hatin'. You'd appreciate the matter considerably more after you
defined your own language and had its users yell at you for changing
even a small detail.

The situation is at it is, and there's no need to get agitated. We're
all on the same boat, trying to make things work out best.


Yeah, no problem. I mean I wasn't bashing D for bugs or flaws (before this point at least) anyway. And it's not like I'm cursing here ;)

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.

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.

--
Dmitry Olshansky

Reply via email to