Andrei Alexandrescu wrote:
> 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.
And all those xxx-ability words apply. Such as useability,
comprehensibility, learnability.. etc. There is technical "correctness"
and then there is "the good thing".
>
> 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.
Yeah, jettison clean syntax because it's of little importance. :/
> In C++, next to nobody uses private
> inheritance systematically, and nobody really understands what
> protected inheritance really is.
>
I avoid private inheritance and never used protected inheritance. I use
composition in those cases but that is when B. Meyer's books come of the
shelf for a reread. I was originally talking just about structural
extension (I probably said "composition" but "extension" is a tad better
term) via inheritance syntax. "inheritance" isn't the key thought in all
of that. "extension" and "syntax" are.
> 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.
"orthogonal" is a bit strong, but I left it in. Let's face it, when you
derive, you get data members and methods. In a struct with no methods,
you get data members only, in a nice clean way. I find that compelling,
syntax-wise.
>
>>> 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.
We'll have to agree to disagree on this one then. I'm sure there will be
others. ;)
