Disable GC entirely

[Dmitry Olshansky]

09-Apr-2013 20:48, Manu пишет:
> On 10 April 2013 00:50, Dmitry Olshansky <dmitry.olsh at gmail.com
> <mailto:dmitry.olsh at gmail.com>> wrote:
>
>     09-Apr-2013 14:18, Manu пишет:
>
>         On 9 April 2013 13:09, Rob T <alanb at ucora.com
>         <mailto:alanb at ucora.com> <mailto:alanb at ucora.com
>         <mailto:alanb at ucora.com>>>
>
>         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