Finalize on vs requires for super mixins

[leafpetersen]

Split off from #7 for continued discussion and resolution of the choice of syntax for the superclass constraints.

cc @Hixie @munificent @lrhn @InMatrix

[bwilkerson]

In the absence of concrete data to help us make a decision, I would prefer requires. I think it's much more evocative of the semantics of the feature.

[munificent]

I'd be happy to put some time into crafting a survey to try to get some user feedback on this if that would be helpful. I'll need some sanity checking from @InMatrix to make sure I'm not doing something dumb, but I can do the manual labor.

[leafpetersen]

Thinking about this last night, there is a consistency argument for requires. The general form of class declarations in Dart is NOUN NAME VERBS NAME, NAME (e.g. class M extends B, class M implements I). The on syntax doesn't follow this: it has the form VERB NAME PREPOSITION NAME. The requires syntax on the other hand follows the same pattern as the others.

[leafpetersen]

I'd be happy to put some time into crafting a survey to try to get some user feedback on this if that would be helpful.

I'd be very happy to get some data on this, if we can do so very expeditiously.

[munificent]

The general form of class declarations in Dart is NOUN NAME VERBS NAME, NAME (e.g. class M extends B, class M implements I).

Yes, that was also part of the reason I like requires. Its consistent with the other keywords.

I'll try to come up with some kind of survey or something we could send out.

[munificent]

Leaf and I spent a lot of time talking about this. I now have a much better understanding of how the on clause works and (I think) a better sense of when users should and should not use it.

I believe the typical mental model users have for mixins (if they have any model of them at all) is something like this: If you have some class that can X and a mixin that knows how to Y given an X, you can slap that mixin onto the class and now you have a class that can X and Y. I'm being hand-wavey about linearization here because I would bet good money that less than 10% of Dart users know anything about how mixins are linearized.

So a typical mixin has some requirements and provides some capabilities. For example, ListMixin requires you provide length and operator[] and in return gives you all of List. The important part is that the superclass of the mixin doesn't have to provide that. It's usually the class itself because usually these requirements are accessed through self calls, not super calls.

If we use requires for stating a mixins superclass requirements, I believe we will encourage users to use that notation for their normal requirements. That in turn produces mixins that are too conservative and will generate errors when you try to mix them into a class that does meet the requirements but whose superclass doesn't.

So, personally, I'm not enthused enough about requires to want to put time into user testing it. I'm not crazy about on. I think it's kind of vague and implies a directional metaphor that isn't meaningful to most users. But I don't have any promising alternatives either.

Perhaps super implements? It's a mouthful, but we're talking a rarely used corner of a rarely-used feature. Maybe it should be long and precise.

[Hixie]

How about "extends"?

[munificent]

Good suggestion. We talked about that too. It's technically feasible with the new syntax and I personally think it somewhat conveys the right thing. But I think it will really throw people off to see a mixin with an extends clause containing multiple "superclasses".

In class definitions, an extends clause does something concrete — it binds a specific superclass. It's part of making the class. If we were to use extends for mixins, it would mean something different. More of an abstraction, a requirement of something that must be done when you use the mixin, but that hasn't been done yet.

There is a lot of overlap, but that leads me to worry that the two concepts are different enough that overloading the word will just sow confusion in both directions.

super is another option we talked about. That conveys about the right thing, but it gets really weird if we ever want to support upper bounds on type parameters (which would probably use super like Java does since we use extends like Java does for lower bounds). That would mean that super Foo means two entirely different things when following a type parameter versus in a mixin declaration.

[Hixie]

"extending" or "for" might also work.

[InMatrix]

Let me know if you guys are still thinking about doing a survey about this choice. Given the subtle implications various word choices can have as discussed above, I doubt asking about the user's initial understanding of the proposed new syntax can resolve this issue. In addition to that, we probably need to present a few usage samples, and ask respondents if they believe the sample will be legal under the new mixin proposal or whether it does A, B or C.

[leafpetersen]

I think on balance, I don't think the price/performance tradeoff of doing a study here comes out well. This is a very new and different feature: as @InMatrix suggests, even to get to the point where we can get meaningful data from a user would require some investment in education. If there are no strong objections (and at this point I don't see any), I'd like to close this and move on with the existing syntax.

[munificent]

👍

[lrhn]

@Hixie About extends, I'd prefer to save that keyword in case we want to enable composite mixins in the future. Example:

mixin ListMixin<E> on Iterable<E> {
   ...
}
mixin UnmodifiableListMixin<E> extends ListMixin<E> {
  ... throwing modifying methods ...
}
class MyUnmodifiableList<E> = MyIterable<E> with UnmodifiableListMixin<E>;