09-Apr-2013 20:48, Manu пишет:
On 10 April 2013 00:50, Dmitry Olshansky <[email protected]
<mailto:[email protected]>> wrote:
09-Apr-2013 14:18, Manu пишет:
On 9 April 2013 13:09, Rob T <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
wrote:
On Monday, 8 April 2013 at 08:21:06 UTC, Manu wrote:
The C++ state hasn't changed though. We still avoid virtual
calls like the
plague.
One of my biggest design gripes with D, hands down, is that
functions are
virtual by default. I believe this is a critical
mistake, and
the biggest
one in the language by far.
My understanding of this is that while all of your class
functions
will be virtual by default, the compiler will reduce them to
non-virtual unless you actually override them, and to
override by
mistake is difficult because you have to specify the "override"
keyword to avoid a compiler error.
Thus successfully eliminating non-open-source libraries from D...
Making a dependency on WPO is a big mistake.
final class Foo{ //no inheritance
final: //no virtuals
...
}
2 extra words and you are done. The only problem I see is that there
is no way to "undo" final on a few methods later...
Yes, it can not be un-done. And any junior/tired/forgetful programmer
will accidentally write slow code all over the place, and nobody will
ever have any idea that they've done it. It's very dangerous.
Yup.
Well for that matter I had a wild proposal on the back-burner to ditch
the whole OOP part of D and/or redesign it. And the reasons roughly go
like this:
What we have is an inforced model with a bunch of arbitrary choices that
fail short on the "one size fits all" promise :
single inheritance, all virtual (yet private is always final), GC-ed
infinite lifetime model backed-in, reference semantic (that might be
fine), "interface is not an Object" etc..
Basically it's a set of choices that doesn't give you any of control
over internals (life-time, object layout, virtuality, ABI). Yet it
presents all of them together in a form box with half-usable knobs like:
- hidden v-table (always!)
- obligatory TypeInfo
- the lame copy-paste monitor mutex from Java
- etc.
Yet what I think is needed is getting the orthogonal concepts:
- custom polymorphic behavior (WHEN you need it and HOW you need it)
- being able plug into a COM of your choice (GObject, MS COM, XP COM,
your own object model etc.)
- optional "pay as you go" reflection (extends on the previous point)
- control over ABI (with potential for true late-binding)
- life-time policy: RC, GC, anything custom including manual management
All of this should be CUSTOMIZABLE and DECOUPLED! Give people the
frigging control over the OOP breed they want to use.
Providing people a toolkit not a one-button black box (and that button
keeps getting stuck!) would be awesome.
Say I want v-table and late-binding for a set of methods and want a
particular ABI for that. And it be manually managed/staticaly allocated.
No typeinfo and half-ass reflection (=boat). There is no such thing in D
(and in C++ for that matter as it has no "fit this ABI" too). It feels
like I'm back to C + preprocessor or ASM.
And again to have great interop with OS/engine/framework it has to be
able to follow some PLATFORM-SPECIFIC object model like Obj-C one. (We
sort of has it with M$ COM, but again why only M$ and why it's built-in
into the _language_ itself?)
If compiler front-end manages to deliver on "multiple alias this" and
other features then it could be done (half-decently) in library. Of
course, some generic compiler support could help here and there.
Quiz: why do D structs look like powerhouse that has all of the tricks
and classes look like poor lame Java wannabes?
--
Dmitry Olshansky
