What are the prominent downsides of the D programming language?

[H. S. Teoh]

On Tue, Sep 29, 2020 at 10:02:28PM +0000, Jean-Louis Leroy via Digitalmars-d wrote:
> On Tuesday, 29 September 2020 at 21:43:03 UTC, mw wrote:
> > The key idea is to treat each parent's class attributes individually
> > (via rename/undefine/redefine/select) instead of as in other
> > multiple inheritance languages, e.g. C++'s all-or-none approach,
> > i.e. either all the parents' attributes are shared or separated, and
> > even when separated, there is no proper renaming mechanism to handle
> > it.
> 
> If Base has features f and g, and Derived inherits from Base but
> undefines g, I assume that a Derived object cannot be substituted for
> a Base. Correct?

This would break Liskov Substitution, wouldn't it?

In any case, Eiffel-style multiple inheritance with undefine/redefine
sounds to me more and more like a case of composition rather than
inheritance. IOW you're not really dealing with subclasses that can be
treated as instances of the base class anymore; you're dealing with
pulling in {methods,fields,etc.} from the base class and arbitrarily
modifying them to produce a new object that may or may not even
substitute for the base class anymore in the Liskov sense.

Frankly, whenever I'm faced with this sort of free-for-all Lego-style
object composition, I throw inheritance out the window and instead write
my own infrastructure for object composition. Like an entity-component
architecture or some such, that confers much more flexibility (and has
cleaner implementation / saner semantics) than a free-for-all
inheritance system.

I mean, sure, being able to undefine/redefine base class members is all
nice and everything, but it's very hard to reason about. (Systems with
erasure semantics are generally hard to reason about.) I'd rather make
it explicit by representing it with an entity-component storage system
than trying to shoehorn it into some kind of inheritance hierarchy with
an arbitrarily-imposed hierarchical system. IME, objects that need
arbitrary composition operations to define generally also fit poorly
into a hierarchical system; I prefer using a true compositional system
like ECS where (1) it's explicit what exactly you're trying to do, and
(2) it's actually maximally flexible, in that you can add/remove
arbitrary combinations of components to your entities, and (3) this can
be done even at runtime, no lock-in to a specific memory layout.


T

-- 
Creativity is not an excuse for sloppiness.