Removed Type-Defect label.
Added Type-Enhancement, Area-Language labels.

This comment was originally written by drfibonacci@google.com

Added Triaged label.

This comment was originally written by carstenkl...@yahoo.de

The same (here: your example given) could be realized by just inheriting CollegeStudent from Worker...

Basically you are just asking for multiple inheritance at the class level.

This comment was originally written by binary...@binarysplit.com

The given example has an obvious diamond problem (What does CollegeStudent.schedule() return?), and thus appears to just be multiple inheritance in disguise.

My understanding of traits (based on Scala's traits http://www.scala-lang.org/node/126 ) is that they're just interfaces that can contain method bodies. These method bodies can only access the other methods and accessors that the trait declares. When a class is extended with a trait, the defined methods are automatically implemented in that class.

It is technically a subset of multiple inheritance, but much it's easier to think of as an extension of interfaces that can reduce code in situations where every implementing class would have the same definition of one of the interface's methods.

I don't think Dart should have Multiple Inheritance due to the complexity of implementing it in a static compiler, but Traits are quite easy to implement, and provide a lot of the flexibility otherwise desired from Multiple Inheritance.

I'm renaming the issue so that its clear what this is about. The confusion between mixins (or their close cousins, traits) and interfaces is not uncommon, but it is confusion nonetheless. Interfaces should not become mixins, but it would be very nice to support mixins in the language. That is something we are considering, but cannot give any commitments on at this time.

Changed the title to: "Support mixins".

Set owner to @gbracha.

This comment was originally written by remi....@gmail.com

Another option is to just allow to add code in interface but no field.
Cf defender methods in Java

Marked this as blocking #1492.

This comment was originally written by demis.bellot...@gmail.com

+1 also think we need something in this area to be able to succinctly add helpers to existing types. If not traits or mixins than something ala C# methods, or Go langs interface methods.

Either way being able to enhance existing types prevents unnecessary forced abstractions (for devs who inheirt types just to be able to add their own helpers), promote more readable and require less code at the call-site, e.g:

StingUtils.indent(Helper.toCustomFormat(obj));

obj.toCustomFormat().indent();

This comment was originally written by @MarkBennett

Taken from a G+ post I did on this topic... https://plus.google.com/104431949275766772757/posts/BUUeiqhebJC

<rant>

Having had this experience developing large apps in languages with (Ruby, JS, Scala) and without (Java, Python) support for mixins, I am strongly in favour of this feature being added to +Dart : Structured web apps for the following reasons:

First, Interfaces are useful for encouraging well defined interactions between application elements, but they also introduce significant places for code duplication as the interface is implemented in different classes. Define once, write many times makes re-factoring a challenge as the same implementation appears many places throughout the codebase. Mixins address this by providing a shared default implementation which can be extended by classes only when necessary. Defining code in one place reduces the size of the code base and less code to maintain means less potential for unhandled bugs.

Second, mixins can be implemented in such a way that method lookups can all be resolved at compile time preventing any extra lookups during method calls and other performance considerations. This also allows tools to identify potentially conflicting mixin methods. This is not true if implemented using something like Ruby style mixins, but would be true of Scala style traits.

Third, there are well understood ways to consistently resolve method name conflicts between mixins. As long as method resolution is expressly covered in the specification, then tooling can support it and assist developers in understanding which methods will be called when.

Admintedly, there are some rough edges with mixins which can result in some confusion. For example, consider the case where Mixin A and B both implement a #to_s () method. Mixin A and B also both use the #to_s () method in their default implementations expecting a different value to be returned. When these mixins are included in Class X, which #to_s () implementation is used, and which #to_s () method is resolved in the default implementations of Mixin A and B? This situation is theoretical, and my experience in Ruby and JavaScript has taught me that it's not something most developers are likely to experience in real applications, but it is a possibility which will need to be handled by the spec. This is one reason why I firmly believe that any implementation of mixins needs to be able to resolve all Class methods at compile time so developer tools can identify and assist developers in resolving issues like this before code is released.

To wrap-up I really feel that mixins are a valuable part of a modern language, and a tool which can be used to reduce the size and complexity of a code base. They're also a great way to share rich behaviours across a broad range of objects. For example, consider the power of things like the Enumerable mixin in Ruby.

Thanks for reading this post, and taking the time to reflect on the future of web programming. Excited to see how responsive and accessible the Dart team has been making themselves.

</rant>

This comment was originally written by george.moscho...@gmail.com

+1 traits/mixins are really missing from the language

This comment was originally written by rtimo...@gmail.com

Traits can be very useful dealing with specialized collections, which have multiple implementations. Say you have a collection Customers, with a method fromCountry(Country c). The implementation is would be something like => _internalList.filter((customer) customer.country == c);

If you have multiple collection classes for Customer, say an Immutable and Mutable variant, or maybe a Set and List, you can simply inherit the trait, and have fromCountry implemented in both. No subclassing, wrapping or a seperate class with static methods is required this way, simplifying code.

Added apr30-triage label.

Removed apr30-triage label.

Added triage1 label.

This comment was originally written by demis.bellot...@gmail.com

I originally articulated my thoughts on why we need mixins here: https://github.com/mythz/DartMixins#the-need-for-mixins but I'll re-post my thoughts here in-case the link gets bit-rotted...

Basically the problem is that all core types in Dart (i.e nums, ints, strings, Lists, Maps, etc) are interfaces (which is good) but also means defining additional functionality causes un-due friction since it forces all interface implementors the burden of providing an implementation.

i.e. You have two opposing forces:

1. To provide useful functionality for built-in types
2. Not to burden all implementations with maintaining repetitive implementations

If Dart supported Mixins it would allow a single implementation to be shared by all collections.

For an illustrative example let's look at the Collection interface:

Collection extends Iterable
    bool every(predicate)
    Collection filter(predicate)
    void forEach(lambda)
    bool isEmpty()
    int get length()
    Collection map(lambda)
    bool some(predicate)

Out of these only the Iterable interface and length() getter are required since the rest of the API could be added via Mixins, e.g:

Collection c = ..;
void forEach(lambda) => for (var e in c) lambda(e);
bool isEmpty() => c == null || c.length == 0;
...

I don't think the current convention of plurazing the Interface type is a great convention since the core Dart library 'takes' the most obvious name
but provides very little functionality in return, e.g The http://api.dartlang.org/dart_core/Strings.html and http://api.dartlang.org/dart_core/Futures.html classes only have 3 static methods between them, but prevents others from creating static utils with the same name.

This comment was originally written by @tomaszkubacki

i think c# way is way better with extension methods because no need for new keywords except using already known "this"

e.g adding isEmail method to String type could look like:

bool isEmail(this String s) => { check_if_email_logic_comes_here }

then usage:

String s = "someone@google.com"
if(s.isEmail()) {
...
}

Most important reason to add extension methods is that they allow extend core lib types with less common or domain specific functionality.

Also building whole new libs as extension methods is widely used in other languages e.g ServiceStack.OrmLite is a set of high level orm extension methods over low level IDbCommand.
See tutorial at https://github.com/ServiceStack/ServiceStack.OrmLite for more details.

This comment was originally written by ladicek@gmail.com

i think c# way is way better with extension methods

FYI, it was already explained a lot of times that C#-style extension methods are a no-go for Dart, because they depend on types. One of Dart's core principles is that type annotations never affect runtime semantics, which is pretty much incompatible with the very idea of extension methods.

This comment was originally written by @ahmetaa

Not an expert on this issue but there is also Java 8 defender methods to check
http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf