Strong mode: Disallow private collisions induced via mixin

[kasperl]

We want to introduce an error in strong mode that flags all private member (field/getter/setter/method) collisions induced by a separate library applying a mixin.

The suggested name for the error is StrongMode.PRIVATE_COLLISION_IN_MIXIN_APPLICATION.

[kasperl]

CC: @vsmenon @leafpetersen @floitschG

[bwilkerson]

Is there a test case for this? (There's not a lot of detail in this issue, and nobody has volunteered to own the issue.)

[kasperl]

Writing down the test cases for this seems like a very useful exercise. I'll see if I can find time or someone to take a stab at that.

The basic idea is that two private members (fields, getters, setters, and methods) with the same name from the same library shouldn't be allowed to be mixed together through mixin applications in other libraries.

[bwilkerson]

So would the following be an example?

class Mixin1 {
  void _init() {}
}
class Mixin2 {
  void _init() {}
}
class C extends Object with Mixin1, Mixin2 {} // Error because _init came from two separate mixins

[kasperl]

If C is in a different library than Mixin1 and Mixin2 then yes, the intent is that it should be flagged. Maybe @vsmenon can confirm the intent?

[vsmenon]

Right, what @kasperl said.

In general, when a programmer is applying a mixin from a different library, the analyzer will need to check that it doesn't cause a private member collision (which must also involve a class/mixin in that other library).

The intent is to let the programmer and compiler reason about a library's private members without worrying about how downstream code may accidentally use them / override them. The intuition is that it's unlikely that the downstream programmer intended the private member conflict.

[bwilkerson]

I'm working my way toward a guess at the specification, but I should have started by asking whether there is an informal spec for this. If so, you can probably ignore this next question.

So what about indirect in-mixing? For example, if we have in lib1.dart:

class Mixin1 {
  void _init() {}
}
class Mixin2 {
  void _init() {}
}

and in lib2.dart:

class A extends Object with Mixin1 {}
class B extends A with Mixin2 {} // Error?

[vsmenon]

This thread is probably the closest thing to an informal spec right now. :-)

Yes, the intent is that would be a collision. lib2 is applying Mixin2 from lib1 and it's creating a collision on _init.