Random thought: Alternative stuct

[H. S. Teoh]

On Wed, Sep 05, 2018 at 07:21:51PM +0000, kinke via Digitalmars-d wrote:
> On Tuesday, 4 September 2018 at 04:03:19 UTC, Mike Franklin wrote:
[...]
> > Rather, we should deprecate classes, and make and expand the
> > capabilities of structs.  Languages like Zig and Rust have done away
> > with classes and all runtime overhead that accompanies them, and are
> > showing great promise by expanding on structs with much more
> > composable features.
> 
> I'm not familiar with the mentioned languages, but I definitely
> wouldn't want to miss classes for good old polymorphism. I'm not too
> fond of the implicit monitor field, but otherwise I find the
> struct/class distinction in D more or less perfect.

+1.  I think the current class/struct divide is perfect. Classes being
intended for runtime polymorphism (which *does* have its uses, in spite
of OO fanatics attempting to shoehorn every problem into it, which is
the reason for the resentment against it) obviously makes sense to be
allocated on the heap by default and passed around by reference. Structs
being glorified ints obviously should be fixed size and passed by value.

The current issues with classes stems really from poor quality of
implementation rather than an actual, fundamental problem with the
design.  The monitor field is an unnecessary, cumbersome overhead that
we could do without, as are opEquals, toString, and their ilk (esp.
given the problem of attribute incompatibilities).

So what we should fixing is the implementation of classes, not throwing
out classes with the polymorphic water completely.


T

-- 
INTEL = Only half of "intelligence".