On 3/15/11 2:07 PM, Jens wrote:
Andrei Alexandrescu wrote:
STL's mild abuses of inheritance (in the absence of something better
such as aliases) are known and understood without being condoned at
large. For a good account of why composition is preferable to
inheritance, you may want to refer to
http://www.artima.com/cppsource/codestandards3.html and the referred
bibliography.
Knowing where to break from "absolutisms" is important. There's nothing
wrong with doing extension of structs via derivation.
With amendments (data protection, lvalue vs. rvalue access, hooks upon
conversion to base...), sure. That's why we included alias this as a
mechanism that encompasses such functionality (including user-controlled
conversions) without adding one language feature for each.
Composition means access through the members rather than direct
access: struct point
{
int x;
int y;
};
struct point3d
{
point pt;
int z;
};
...
point3d mypoint;
mypoint.pt.x = 3; // ugly
The reason for the allegedly ugly syntax is that it's considerably
more general.
Over-generality is a key thing that gets languages in trouble.
This is general enough to be too vacuous.
It is easily observable. Knowing where to draw the lines is key. In this
instance, I think he blew it.
He being whom?
We figured we need a better
subtyping mechanism for structs and designed 'alias this' for that
purpose. How is this getting D in trouble?
I won't use it.
How is you not using 'alias this' is getting D in trouble?
It is often the case that a struct defines an entity
that is implicitly convertible to another entity - could be an
rvalue vs. lvalue, a class vs. another struct vs. a primitive type,
could need a run-time operation etc. Inheritance would offer at
best few of these amenities, whereas 'alias this' offers all with a
simple syntax.
What's wrong with conversion operators? I wouldn't use "simple" and
"ugly" in the same sentence. I would have chosen a different design.
Please give detail on the design you would have chosen, thanks.
I have no problem with a C++-like way. I think it needed not been
drastically departed from. I have an object model planned but I'm not
about to detail it here. Sometimes I wonder if D has the goal of changing
as much as possible just for change sake.
You'd have better success with substantiating that point using pretty
much any other feature. This is a losing pick.
D was designed by people very familiar with C++, appreciative of its
qualities, and aware of its issues. A cosmopolitan community also
provided input to the design. Inadvertent C++ object slicing was
considered (and for good reasons I think) a major issue in C++ that
needed to be addressed. There would definitely be several ways of
addressing it, but using sheer inheritance for polymorphic classes and
'alias this' for monomorphic structs is a very robust combination.
Andrei
