On 3/15/11 1:54 PM, Jens wrote:
Jesse Phillips wrote:
Jens Wrote:
OK, silly me. I used a wrong example. I really did want to know about
non-polymorphic composition from structs via derivation. Sorry for
the confusion.
struct point
{
int x;
int y;
};
struct point3d: point
{
int z;
};
You already got your answer 'alias this' which you have dismissed as
ugly. You wanted composition and I think it provides a very clean way
to describe composition, especially since it looks nothing like how
inheritance of classes which have polymorphic behavior.
Inheritance and polymorphic behavior can be (should be IMO) orthogonal.
In concept it's easy to abide to strong stances, and I wouldn't disagree
it's not half a bad thing. However, real-world issues do arise.
Inheritance is often a desirable mechanism for implementing dynamic
polymorphism for two main reasons. One, it prevents accidental
polymorphism from happening. Two, it allows the compiler to lay out
objects efficiently and make function invocation relatively fast without
a need for global information. Offhand I don't think there are other
reasons.
Inheritance without polymorphism is technically possible, but rarely of
any practical interest. In C++, next to nobody uses private inheritance
systematically, and nobody really understands what protected inheritance
really is.
Polymorphism without inheritance is the election mechanism during
compilation, and possible for runtime polymorphism with well-understood
reflection mechanisms (btw I see now that adaptTo has not been yet added
to std.typecons...)
All in all inheritance is strongly associated with polymorphism as it is
a basic mechanism for implementing it, so it would be tenuous to force
the two to be orthogonal.
Also note the
intent is to allow for multiple 'alias this' declarations, but hasn't
yet been implemented.
struct point
{
int x;
int y;
};
struct point3d
{
point p; // I own a point
alias this p; // I am a composition of a point p.
int z;
};
I didn't ask how to do composition in D. I asked why composition cannot
be done via derivation, i.e., the reasoning behind the language design
choice. A design faux paus IMO.
I would agree, with the slight amendment that this time for once the
faux pas is in the design of the application, not that of the language.
Andrei
