"includes" instead of "implements" for view composition

[munificent]

The views proposal uses implements to allow one view type V1 to build off other view types V2, etc. As I understand it, this clause does two things:

1. All of the instance members defined by V2 are made accessible as instance members on V1. By "instance" here, I mean that the constructors and static members of V2 are not made available. The dispatch is still purely static. It's almost as if the instance declarations in V2 have been textually copied to V1.

2. V1 becomes a subtype of V2. This allows establishing a subtype hierarchy among a family of related view types who all share a related representation type.

This behavior seems totally fine to me. However, I find implements a confusing word to express that, for a couple of reasons:

• In classes, implements specifically means that you do not inherit any implementation. Of course, with views, there is no real "inheritance" going on, it's just that the subtyping induced allows the members on V2 to be available as extension members on V1. But informally, it feels very strange that an implements clause gives you implemented functionality.

• In classes, implements adds a requirement to the class. When you add an implements, your class now has an obligation to define or inherit implementations of all of those members. Adding implements can require you to do work in your class declaration. With views, implements gives you stuff "for free" and doesn't require you to add anything (except possibly redeclaring to avoid collisions).

• In classes, and in other languages, implements implies some level of runtime polymorphism and dynamic or virtual dispatch. It suggests that the thing being implemented is an interface and the class can now be used wherever that interface is allowed, and its instance members are now polymorphic implementations of that protocol. None of that applies to views where all dispatch is entirely static.

In short, it feels like a confusing keyword choice to me. Instead, I propose includes:

view class V1(int i) {
  void v1() {}
}

view class V2(int i) {
  void v2() {}
}

view class V3 includes V1, V2 {}

I think that word conveys that all of the functionality defined by the superviews is now available by the subview.

It might be confusing that a new word includes also induces a subtype relation. But I believe we already have that in Dart and it doesn't seem to cause much confusion in practice. The keywords extends, implements, and with all also mean that the class containing that clause becomes a subtype of the type in the clause. So this would just be one more keyword where that's true.

I also think the subtyping aspect is less important than the code reuse aspect. When users are reading a program, they mostly want to know where the code that gets called is and how it is reached. Using includes suggests that "Ah, this method I can see being called on V3 must have been included from V1".

[lrhn]

I don't like includes for two reasons:

1. It's new. We'd have to tell people what it means from scratch.
2. It's incredibly generic. There is probably no hierarchy based relation which can't be imprecisely described by "includes" (in one direction or the other). I'd rather use alsoviews. For all its other brokenness, it's at least precise.

The benefit of implements is that if we introduce non-virtual methods on classes (and primary constructors),

view class Foo(int x) {
  int get foo => 42;
}
view class Bar(int x) implements Foo {
  int get bar => 37;
}

behaves equivalently to:

class Foo(int x) {
  nonvirtual int get foo => 42;
}
class Bar(int x) implements Foo {
  nonvirtual int get bar => 37;
}

wrt. resolution of non-virtual methods. A view is just a class-like thing where methods are non-virtual by default.

What I don't like is that implements is universally used for interfaces, and views do not introduce interfaces.

What I'd like about extends instead is that it describes the intent.

view class Foo(int _x) {
  int get foo => 42;
}
view class Bar(int _x) extends Foo {
  int get bar => 37;
}

suggests that the Bar members extend the Foo members and the Bar view is a specialization of Foo.

The corresponding classes-with-nonvirtual-members would be:

class Foo(int _x) {
  nonvirtual int get foo => 42;
}
class Bar(super. _x) extends Foo {
  nonvirtual int get bar => 37;
}

It includes all super-class/view member implementations. For views, that's only the non-virtual ones, but it's still correct.

The issue is that you can extend more than one view.
The benefit of using extends for that is that we can reasonably make the source order of the super-views matter for member shadowing, which would feel odd for implements.

Heck, we can allow all of the modifiers both:

view class Foo extends Bar, Baz with Qux implements Twix {}

Then you can use whatever you like, it's all the same for non-virtual methods.

[munificent]

What I don't like is that implements is universally used for interfaces, and views do not introduce interfaces.

Perhaps another way to think about is that the verb here tells you something about what kinds of declarations are allowed there. In Dart today:

• The thing after implements must be (or expose) an interface. Assuming we add type modifiers at some point and allow non-interface class declarations, you won't be able to put one of those after implements.
• The thing after extends must be a class. If it's in another library, it must have a public generative constructor. Again, if we add type modifiers, it must be an open class.
• The thing after with must be a mixin. If we eventually restrict it so that classes stop exposing mixins, then it will have to be an actual mixin declaration.

So the word tells you what you can do next. From that angle, implements is a clearly bad choice, because the thing after implements can't be a type that exposes an interface and must be a view class—currently the only kind of type in the language that doesn't have an interface.

[leafpetersen]

This is going to be a pretty hard sell. The word "include" is probably one of the most ingrained terms in programming: 50 years or so of the C pre-processor has pretty well ingrained the notion that if you "include" something you are basically copying it in. It's really hard for me to believe that using "include" here is going to give users the right intuition.

In general, I'm really uncomfortable with using class syntax, but with non-standard affordances. We could talk about using extends and with instead of implements. Or I guess we could try to find an interpretation of include that works for normal classes as well? But if we feel we're going to add non-standard syntax here, then that pushes me pretty strongly towards not re-using the class syntax. But then we end up re-inventing 90% of the class syntax just so we can avoid using one piece of it. And I don't find that very appealing either.

From that angle, implements is a clearly bad choice, because the thing after implements can't be a type that exposes an interface and must be a view class—currently the only kind of type in the language that doesn't have an interface.

Well, there are lots of types that don't have an interface (e.g. function types), and we're about to release more (record types). I don't really see the problem here, but if it bothers you it's completely straightforward to allow class V(SomeType self) implements Foo where Foo is not a view type. We just need the requirement that Foo <: SomeType. It's true that view classes don't expose an interface. I actually have some ideas about how we could make that work, but I don't really think they're worth pursuing.

Perhaps another way to think about is that the verb here tells you something about what kinds of declarations are allowed there.

This may be necessary, but it is not sufficient. If you extend something and you are concrete, it's not enough for it to be a class: it must be a class with a generative constructor. Similarly for other things: there are requirements on the things that you extend, implement, or mixin. One of the requirements here is that any interfaces you implement must be view class interfaces. I'm not sure I find that all that strange. In fact, in the underlying semantic model, it's absolutely well-justified.

I think the main point of concern that I share here is that it is surprising to see members in a view class that do not conform to the signatures in the view class super-interface. Requiring the word extension before the member would make this much clearer, but would be verbose. Perhaps this is an argument for extension class as the naming. Another option would be to explicitly split these out as sticky extensions that are applied from outside the class (but which must be co-located in the same library). Then the semantics become much clearer.

view class V1(int i) {}
class extension on V1 {
  void v1() {}
}

view class V2(int i) {}
class extension on V2 {
  void v2() {}
}

view class V3 implements V1, V2 {}

I don't object to this entirely, and it is in many ways more general: you could perfectly well use these sticky extension on things other than view types, which is nice.

[lrhn]

The way I read extends, with and implements is very much:

• with: Mixes in a mixin.
• implements: Implements an interface, becomes the type.
• extends: Specialize the thing above.

I have pretty fixed expectations of the types after with and implements, but curiously not about what comes after extends - it must just be something of the same kind as the current declaration.
I have been prepared to add extends to mixins, to create composite mixins, since we introduced the mixin declaration.

A class extends a class, a mixin extends a mixin, and a view would then extend a view (or more than one, because multiple inheritance is not a problem).

I guess it could be argued that implements works for interfaces of the same kind too, and view interfaces are different from class interfaces. You still inherit all the member signatures and becomes a subtype, so it's a really good match. You then also get all the implementations, because that's how extension/non-virtual methods work, they attach to the type and work through subtyping.

The one thing that makes me prefer extends over implements is really that implements is unordered, but we can choose to make extends ordered, to define a chain like we normally do with extends clauses, which resolves the inherited member conflicts (last one wins) in a user-configurable way.

[eernstg]

Here is an attempt to gather the main points which have been made in this thread.

I added one more option: Use with (not extends V1 with V2, V3, just with V1, V2, V3). The point is that extends V1 with V2, V3 seems to imply that V1 is one kind of thing and V2 and V3 are of a different kind, and that's misleading; with V1, V2, V3 suggests that they are all the same kind of thing.

Subtyping

Keyword	Reason why it's consistent/good	Reason why it's not
includes	New word for new semantics	Unfamiliar, might not suggest any subtype relationship
implements	The declared view is a subtype of implemented views, as expected
extends	The declared view is a subtype of extended views, as expected	Surprising that we can extend >1 view
extends, with	The declared view is a subtype of extended and mixed-in views, as expected	Surprising that operands have different syntactic positions when they are all views
with	Subtype of mixed-in types, as expected

"Inherited" member implementation availability

Keyword	Reason why it's consistent/good	Reason why it's not
includes	Suggests textual copy, so it's natural that we get the implementation	Textual copy is an imprecise model
implements	Same semantics as nonvirtual and extension methods: always applicable to subtype (but there may be some more specific declarations with the same name)	implements elsewhere does not provide an implementation, we have to write it or get it from somewhere else
extends	Implementation is inherited, as expected	"inherited" is an imprecise model (static resolution)
extends, with	Implementation is inherited, as expected	"inherited" is an imprecise model (static resolution)
with	Implementation is mixed in, as expected	"mixed in" is an imprecise model (static resolution)

Member declaration conflict resolution

Keyword	Reason why it's consistent/good	Reason why it's not
includes	Redeclare conflicting member, which will cancel the 'textual copy'
implements	Same semantics as nonvirtual and extension methods (most specific applicable declaration wins)	Non-standard: Classes don't have implementation conflicts due to implements
extends	Redeclare to resolve conflict, or report conflict at call sites	Non-standard: Classes don't have conflicts in extends
extends, with	Linearization resolves conflicts	What if we want selected members, and no linearization works?
with	Linearization resolves conflicts	What if we want selected members, and no linearization works?

Correct overriding

Developers may very well expect override constraints to be enforced when a view method is declared in a superview and is also redeclared in a subview. We could enforce this, but we do not have to do it. The current proposal allows an arbitrary relationship (including: a view can declare a getter foo and a subview can redeclare foo as a method).

Keyword	Reason why it's consistent/good	Reason why it's not
includes	A textual copy does not suggest any constraints
implements	Same semantics as nonvirtual and extension methods: no constraints	Non-standard: In a class you have to override members from implements correctly
extends	Redeclare to resolve conflict, or report conflict at call sites	Non-standard: In a class you have to override members from extends correctly
extends, with	(Linearization resolves conflicts)	Non-standard: In a class you have to override members from extends and with correctly, but the views here do not have that constraint
with	(Linearization resolves conflicts)	Non-standard: In a class you have to override members from with correctly, but the views here do not have that constraint

Run-time polymorphism

The subtyping relationship among views allows for run-time polymorphism in a way that appears to be very similar to the run-time polymorphism which is supported for objects that are accessed using class types as their static type:

view class V0(num n) {...}
view class V1(int i) {...}

void main() {
  V1 v1 = V1(42);
  V0 v0 = v1; // OK.
  v1 = v0 as V1; // `v0 as int` at run time.
}

The invocation of members is resolved statically, but that doesn't change the fact that we can have a reference of type V1 to a given object, and a reference of type V0 to the same object, and the former is a proper subtype of the latter. In other words, we do have run-time polymorphism.

Keyword	Reason why it's consistent/good	Reason why it's not
includes		Unfamiliar, might not suggest any subtype relationship
implements	Run-time polymorphism exists, as expected
extends	Run-time polymorphism exists, as expected
extends, with	Run-time polymorphism exists, as expected
with	Run-time polymorphism exists, as expected

[lrhn]

Good summary. (In case it was not clear, my vote is for extends + linearization of multiple super-views).

[leafpetersen]

I added one more option: Use with (not extends V1 with V2, V3, just with V1, V2, V3). The point is that extends V1 with V2, V3 seems to imply that V1 is one kind of thing and V2 and V3 are of a different kind, and that's misleading; with V1, V2, V3 suggests that they are all the same kind of thing.

This is a good point.

[munificent]

I'm not in love with with or extends, but I would prefer either of those (slight preference towards extends) over implements.

Have we considered is? Possibly confusing since that may sound more like the representation type instead of the supertypes.

[leafpetersen]

Have we considered is? Possibly confusing since that may sound more like the representation type instead of the supertypes.

The perspective that I keep coming back to is the perspective of the reader of the code. If I go to definition on a view class, and I see:

view class V1(int i) implements V2 {
  int foo() => ....
}

then if I just make the obvious assumptions, I will draw the following working conclusions:

• V1 is a subtype of `V2
• V1 has a foo method with the signature listed above
• V1 has all of the methods of `V2

Those are all, to a first approximation, correct. It's true that V2 may have a different signature for foo, which is different, but that's second order. Similarly, the dispatch is static, no wrapper object, etc. But again, largely second order.

The same is true for with. Any of the obvious assumptions that I make, will be true.

Whereas if I go to definition and see is or includes or something else, which is new, then I don't know what I'm reading. I have to learn something new.

So from the reader's perspective, it seems to me to be universally better to use implements or with.

The objection (which is fair) is that from the writer's perspective, implements and with behave a bit differently. You can only implement other view classes, and you don't get override signature checking, etc. But in general I'm inclined to greatly prioritize the reader of the code here over the writer of the code. That at least has been the perspective that I've been coming from.

[munificent]

• V1 has all of the methods of V2

If I see a class that says class V1 implements V2 { ... } I expect to see all of the methods declared by V2 implemented in V1. If the methods aren't in V1, I'd be confused because... where the hell are they? They aren't coming from V2, because I'm not extending V2. Using implements specifically means "do not inherit any implementation from this class".

If I knew that V2 declared a foo() and I didn't see a foo() in V1, it would look like a broken class declaration to me. How is V1 possibly implementing V2 without declaring foo()?

[leafpetersen]

If I knew that V2 declared a foo() and I didn't see a foo() in V1, it would look like a broken class declaration to me. How is V1 possibly implementing V2 without declaring foo()?

Yes, this is probably a good argument for using with. Would that alleviate your concern here? That said....

If I see a class that says class V1 implements V2 { ... } I expect to see all of the methods declared by V2 implemented in V1. If the methods aren't in V1, I'd be confused because... where the hell are they?

Here is a class declaration that our users work with every day. That class definition claims (indirectly) to implement Iterable, and yet there are no definitions of those methods implemented anywhere in its body or its superclass hierarchy.

Are you confused by it? Do you think our users are confused? I mean, it is a bit confusing, if you dive into it. But mostly, you don't care. Most of the time, you're just going to say "oh, this class implements Iterable<int>, so in some way it has the right methods, who cares how". It's pretty rare that you actually care where the methods come from. And in fact, they may not come from anywhere - so if you really want to understand it, you need to understand that an abstract class doesn't have to provide implementations of the things that it implements, and that the actual implementation will be provided by some concrete class which implements the abstract class, yadda, yadda, yadda. And likewise, if you really want to understand where the V2 methods come from, you need to understand that a view class provides extension methods, which are attached to the type, and so the methods come along with the super-interface, yadda, yadda, yadda.

Now it's definitely true that the interface/implementation split is pretty standard now, and people have internalized it in a way that they won't have for something new like a view class. So I certainly don't claim that this is a non-issue. But I do question whether this is something that's actually going to be a pain point for users in practice?

[eernstg]

One area where pre-existing mental models may be helpful for developers who are getting acquainted with views is conflict resolution:

• implements on a class can give rise to member signature conflicts (two different member signatures with the same name), and this kind of conflict is in general resolved by overriding the given member (if it's possible to resolve the conflict). There is no notion of ordering or priority.
• extends ... with ... on a class resolves every conflict by linearization (if it can be resolved).

So we might want to link these properties to the handling of conflicts with views: If every conflict must be resolved by redeclaring the conflicted name then we might want to use implements; if conflicts should be resolved silently by linearization then we might want to use extends ... with ... or with ....

[lrhn]

One advantage of implements is that it's clear that you won't call superclass constructors. Which we won't. Unless we want to?
Can one write:

view class FooView implements BarView {
  final int x;
  FooView(this.x) : super.special(x); 
}

to explicitly invoke the superclass constructor, if I really, really want to?

Or should I just write it as:

view class FooView._(BarView x) { 
   FooView(int x) : this._(BarView.special(x));
}

(Can I have view class Foo(super.value) to avoid introducing a new name for the this as RepresentationType, if I don't want one).

Apart from that, after talking more with both @eernstg and @leafpetersen, I'd probably be satisfied with extends ... with ...,..., where extends can only take one view class, and with can take any number of views. Both extends ... and with ... are optional.
The super-views are linearized, like extends and with normally do.

It is as if view classes can be used both as view superclasses, and also as view mixins, like some classes can.

Most views will only extend one other view, in order to inherit its API, and using extends feels fine for that.

Views which combine more than one super-view will likely have some of the other views be "mixin-like" (intended to go on top of another view and add or modify a few members), and it might make sense to the author to use with for that.

You get to show a kind of intent in whether you use extends or with, even if it doesn't matter and you can just use with ... for everything.

(But not calling superclass constructors makes me worry a little about extends).

[munificent]

Yes, this is probably a good argument for using with. Would that alleviate your concern here?

I think with could be reasonable, yes. It's already sort of vague (no one really knows how mixins are applied) but does generally mean "you get the stuff from that type here too".

That said....

If I see a class that says class V1 implements V2 { ... } I expect to see all of the methods declared by V2 implemented in V1. If the methods aren't in V1, I'd be confused because... where the hell are they?

Here is a class declaration that our users work with every day. That class definition claims (indirectly) to implement Iterable, and yet there are no definitions of those methods implemented anywhere in its body or its superclass hierarchy.

Are you confused by it? Do you think our users are confused? I mean, it is a bit confusing, if you dive into it.

It's confusing for users who don't understand abstract, yes. But for others, they can figure out that, "Ah, the methods aren't here yet because this is an incomplete class. Once I find the non-abstract class that extends this, I'll be able to find the implementations of everything."

In other words, with abstract class List implements Iterable, the List class indeed does not have any implementations of those methods on Iterable. I don't see them when I look at the class, and they are in fact not there. It's only some concrete subclass of List that will have them.

Whereas with a view class, if we use implements, I also won't see the implementation of methods. But this time they are there because they were inherited from the superinterface. That feels like an entirely different mechanism to me.