> On Feb 12, 2015, at 10:27 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> 
> this thousand times ... Traits as class makes no sense to me indeed and Mark example shows plain objects passed as Trait.create ... that works just fine, except some trait initialization, which should not be a constructor, could be used too.
> 
> Is there any other language that uses same classical OOP classes as traits too? It really does not feel right to me.
> 
> Btw, reason I'm asking is because somebody else asked, I'm really OK to not rush and wait to see how it goes when it's the right time.
> 
> Best Regards
> 
> On Thu, Feb 12, 2015 at 6:32 PM, Luke Scott <luke at cywh.com <mailto:luke at cywh.com>> wrote:
> 
> I would agree with that. I had a trait implementation that used classes as traits, and it caused a lot of problems, especially since classes have constructors. Traits should not have constructors. I have since updated my implementation to use plain objects.
> 
> This is what I am using now: https://gist.github.com/lukescott/36453a75c39c539f5c7d <https://gist.github.com/lukescott/36453a75c39c539f5c7d>
Based on the gist I provided, this is how I would envision the ES7 version looking like:


trait Trait1 {
  method1() {}
}

trait Trait2 {
  method2() {}
}

trait Trait3 {
  mixin Trait2;

  method3() {}
}

Trait3 hasTrait Trait2 // true
Trait3 hasTrait Trait1 // false

class Foo {
  mixin Trait1;
}

Foo hasTrait Trait1 // true
Foo hasTrait Trait2 // false

class Foo2 extends Foo {}

Foo2 hasTrait Trait1 // true
Foo2 hasTrait Trait2 // false

class Foo3 extends Foo {
  mixin Trait2;
}

Foo3 hasTrait Trait1 // true
Foo3 hasTrait Trait2 // true

class Bar {
  mixin Trait3;
}

Bar hasTrait Trait1 // false
Bar hasTrait Trait2 // true
Bar hasTrait Trait3 // true


As far as conflict resolution goes, you could go by trait order (last one wins), or simply throw an exception when mixing in two traits with the same methods. A conflict would look like this:

trait Trait1 {
  someMethod()
}

trait Trait2 {
  someMethod()
}

class Foo {
  mixin Trait1, Trait2;
}

OR

class Foo {
  mixin Trait1
  mixin Trait2;
}


But this would not be a conflict:


trait Trait1 {
  someMethod()
}

trait Trait2 {
  mixin Trait1;
  someMethod() // Override method from Trait1
}

class Foo {
  mixin Trait2;
}


PHP has traits, but has a way to resolve conflicts by specifying which method should be used. I would keep it simple and make conflicts an error outright or last one wins. Most use cases for traits is including functionality that can’t be inherited where you would have to copy and paste methods otherwise.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150212/eac528b4/attachment-0001.html>

On Feb 12, 2015, at 10:27 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

> This is what I am using now: https://gist.github.com/lukescott/36453a75c39c539f5c7d <https://gist.github.com/lukescott/36453a75c39c539f5c7d>

Based on the gist I provided, this is how I would envision the ES7 version looking like:

```js
trait Trait1 {
  method1() {}
}

trait Trait2 {
  method2() {}
}

trait Trait3 {
  mixin Trait2;

  method3() {}
}

Trait3 hasTrait Trait2 // true
Trait3 hasTrait Trait1 // false

class Foo {
  mixin Trait1;
}

Foo hasTrait Trait1 // true
Foo hasTrait Trait2 // false

class Foo2 extends Foo {}

Foo2 hasTrait Trait1 // true
Foo2 hasTrait Trait2 // false

class Foo3 extends Foo {
  mixin Trait2;
}

Foo3 hasTrait Trait1 // true
Foo3 hasTrait Trait2 // true

class Bar {
  mixin Trait3;
}

Bar hasTrait Trait1 // false
Bar hasTrait Trait2 // true
Bar hasTrait Trait3 // true
```

As far as conflict resolution goes, you could go by trait order (last one wins), or simply throw an exception when mixing in two traits with the same methods. A conflict would look like this:

```js
trait Trait1 {
  someMethod()
}

trait Trait2 {
  someMethod()
}

class Foo {
  mixin Trait1, Trait2;
}
```

OR

```js
class Foo {
  mixin Trait1
  mixin Trait2;
}
```

But this would not be a conflict:

```js
trait Trait1 {
  someMethod()
}

trait Trait2 {
  mixin Trait1;
  someMethod() // Override method from Trait1
}

class Foo {
  mixin Trait2;
}
```

PHP has traits, but has a way to resolve conflicts by specifying which method should be used. I would keep it simple and make conflicts an error outright or last one wins. Most use cases for traits is including functionality that can’t be inherited where you would have to copy and paste methods otherwise.