On Thursday, 6 November 2014 at 15:25:11 UTC, Patrick Jeeves
wrote:
> On Thursday, 6 November 2014 at 08:04:33 UTC, Ola Fosheim Grøstad
> wrote:
>> On Thursday, 6 November 2014 at 00:50:23 UTC, bearophile wrote:
>>> I think not giving language support means that D designers don't want it to be easy to do. And this is good.
>>
>> Then why are they adding multiple alias this, which appears to be worse?
>
> I don't really see how multiple alias this is better or worse
> than multiple inheritance.  They descirbe completely different
> relationships, Multiple Aliasing describes an is-both
> relationship, while Multiple Inheritance describes an
> is-from-a-certian-point-of-view-a relationship.  Atttempting to
> use compositing to emulate will only result in feature envy, data
> duplication, the space of the bookkeeping needed to share the
> data exceeding the space of the data being shared, cache misses,
> etc.
>

Multiple inheritance have various issue, like the well known
diamond shaped inheritance problem. There are also many
implementation issues when it come to object layout and base
class retrial, which are all trivial with a single inheritance
model.

Considering it come with problems, both in term of language
design and efficient implementation, it has to pull its weight.
And I'm yet to see a good use case for it.

In the other hand, alias this (or prototypal inheritance model in
general) do not suffer from these issues. It also have some good
use case like entity framework.

On Thursday, 6 November 2014 at 21:56:39 UTC, deadalnix wrote:
> In the other hand, alias this (or prototypal inheritance model in
> general) do not suffer from these issues. It also have some good
> use case like entity framework.

I'm curious as to how prototypical inheritance avoids the diamond inheritance problem. Is it due to the fact that it doesn't require a virtual call, and thus, ambiguous cases can be caught at compile time?

On Thursday, 6 November 2014 at 22:15:25 UTC, Meta wrote:
> On Thursday, 6 November 2014 at 21:56:39 UTC, deadalnix wrote:
>> In the other hand, alias this (or prototypal inheritance model in
>> general) do not suffer from these issues. It also have some good
>> use case like entity framework.
>
> I'm curious as to how prototypical inheritance avoids the diamond inheritance problem. Is it due to the fact that it doesn't require a virtual call, and thus, ambiguous cases can be caught at compile time?

Because the base "object" and delegated "object" are different
one, not the same being polymorphic.

On Friday, 7 November 2014 at 03:28:45 UTC, deadalnix wrote:
> Because the base "object" and delegated "object" are different
> one, not the same being polymorphic.

That does not resolve conflicts with having the same base prototype or name conflicts in method names. Ignoring the issues does not make them go away…

On Friday, 7 November 2014 at 07:12:58 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 7 November 2014 at 03:28:45 UTC, deadalnix wrote:
>> Because the base "object" and delegated "object" are different
>> one, not the same being polymorphic.
>
> That does not resolve conflicts with having the same base prototype or name conflicts in method names. Ignoring the issues does not make them go away…

Conflict will cause error and you can specify which road you want to take explicitly. This has nothing to do with alias this, but with identifier resolution in general. imported symobl for instance, suffer from the same issue.

On Friday, 7 November 2014 at 07:41:26 UTC, deadalnix wrote:
> want to take explicitly. This has nothing to do with alias this, but with identifier resolution in general. imported symobl for instance, suffer from the same issue.

The diamond problem involves the desire to only have a single instance of the shared base class. Not a resolution issue.

That said, I don't like unqualified imports much. They tend to make code less readable when you scale up.