@sigmundch, can we pull this back to 1.13? It's needed to complete #23770

Hi @mit-mit, it might be tight for 1.13, which is why I thought was better to push it for 1.14 - @rakudrama was planning on tackling this but he can't get started right away. I'd be happy to chat in more detail if you like.

This is definitely a post- 1.13 feature.

Features that involve mixins are always complicated. Mixins have proven to
be one of the most expensive features of Dart. It is best to assume it will
take two release cycles from commitment to get it working correctly.

There are unresolved problems with the proposal. The main one is that it is
not possible to efficiently implement mixin super calls in JavaScript when
one class is mixed-in more than once in an inheritance chain. I don't want
to agree to implement anything unless either (1) multiple mixins of the
same class (directly or indirectly) are forbidden, i.e. an compile-time
error in all implementations, or (2) someone convinces me how to implement
the feature.

On Wed, Sep 16, 2015 at 9:05 PM, sigmundch notifications@github.com wrote:

Hi @mit-mit https://github.com/mit-mit, it might be tight for 1.13,
which is why I thought was better to push it for 1.14 - @rakudrama
https://github.com/rakudrama was planning on tackling this but he can't
get started right away. I'd be happy to chat in more detail if you like.

—
Reply to this email directly or view it on GitHub
#23773 (comment).

@gbracha, can we forbid multiple mixins of the same class? Or is there some legit reason to support that?

At the moment, one could easily add a restriction to ban duplicates. Long term this is undesirable however for the following reason:

People want to mix in entire chains of mixins (aka mixin composition) so they can easily get the complete behavior associated with a class. We don't support that yet, but it is part of the plan. Once you do that, the chains are much more likely to contain duplicates, and these must be retained in order to preserve the desired behavior (and no, you cannot choose to remove the duplicates, it's been tried and does not work). If we banned duplicates, it would not only disallow certain usages, but also violate encapsulation: a composite mixin might evoilve over time and duplicates might arise where there had been none before, breaking working code.

So at the moment, the issue is really one of implementation convenience. If we make it easier for, say, dart2js by banning duplicates, we add a burden on the VM to check for a situation it already supports. I lean toward doing things right the first time.

As for the claim that it isn't possible to implement it efficiently, that is false. It isn't as easy. The obvious strategy entails replicating mixed in methods and that adds a space penalty. But in fact, you can chhose to do that only when you actually have a duplicated method. That is very rare.

On Mon, Sep 28, 2015 at 7:21 PM, Gilad Bracha notifications@github.com
wrote:

At the moment, one could easily add a restriction to ban duplicates. Long
term this is undesirable however for the following reason:

People want to mix in entire chains of mixins (aka mixin composition) so
they can easily get the complete behavior associated with a class. We don't
support that yet, but it is part of the plan. Once you do that, the chains
are much more likely to contain duplicates, and these must be retained in
order to preserve the desired behavior (and no, you cannot choose to remove
the duplicates, it's been tried and does not work).

Can't help mentioning one more data point here: gbeta removes duplicate
mixins, and there haven't been any problems with that. It's sound and I
tend to think that multiple executions of a given method implementation is
more confusing/inconsistent than the duplicate removal (which is the
natural semantics that you'll get if you retain the duplicates). Of course,
the type of a class in gbeta is a set of mixins, so nobody can depend on
the presence of a specific number >1 of copies of any particular mixin, and
due to the use of virtual classes it also doesn't have the "what about
C and C being present together?" problem. So maybe I just outlined
some of the reasons why you think it doesn't work? ;^)

If we banned duplicates, it would not only disallow certain usages, but
also violate encapsulation: a composite mixin might evoilve over time and
duplicates might arise where there had been none before, breaking working
code.

Indeed; a duplicate removal semantics would tolerate that kind of evolution
as well.

So at the moment, the issue is really one of implementation convenience.
If we make it easier for, say, dart2js by banning duplicates, we add a
burden on the VM to check for a situation it already supports. I lean
toward doing things right the first time.

As for the claim that it isn't possible to implement it efficiently, that
is false. It isn't as easy. The obvious strategy entails replicating mixed
in methods and that adds a space penalty. But in fact, you can chhose to do
that only when you actually have a duplicated method. That is very rare.

The idea that we can omit some methods associated with a mixin application
surprises me a bit. That's how I understand it: with class C extends B with M, M {} we could omit adding a method foo from M for the mixin
application of M to B with M because it is a duplicate of the one we
already added when applying M to B. If foo contains a super
invocation then I would certainly expect its side-effects to occur as many
times as we have duplicates of the given mixin in the superclass chain
(that would be M in the example), and I would also expect reflection to
find the foo method in the mixin application (of M to B with M), even
in the cases where it doesn't contain a super invocation. I think I'll
stick to the idea that duplicate removal is more "understandable" than
duplicate retention. ;)

best regards,

Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

Clearing milestone flag as it's not clear when this work is happening

No longer planned in the proposed form.