atom feed19 messages in Mixin inheritance
FromSent OnAttachments
Brian GoetzMar 13, 2009 11:50 am 
Michael AzziMar 13, 2009 12:43 pm 
Brian GoetzMar 13, 2009 1:20 pm 
Michael AzziMar 13, 2009 1:42 pm 
Weiqi GaoMar 14, 2009 6:24 am 
Kim TopleyMar 14, 2009 7:40 am 
Robert FieldMar 15, 2009 12:53 pm 
Brian GoetzMar 16, 2009 11:18 am 
Brian GoetzMar 16, 2009 11:19 am 
Kim TopleyMar 16, 2009 12:21 pm 
Weiqi GaoMar 16, 2009 7:37 pm 
Brian GoetzMar 18, 2009 11:32 am 
Michael AzziMar 18, 2009 11:56 am 
Weiqi GaoMar 18, 2009 7:09 pm 
Brian GoetzMar 20, 2009 9:11 pm 
Brian GoetzMar 20, 2009 9:12 pm 
Brian GoetzMar 20, 2009 9:18 pm 
Weiqi GaoMay 3, 2009 7:31 pm 
Brian GoetzMay 3, 2009 7:52 pm 
Subject:Re: Mixin inheritance
From:Brian Goetz (Bria@Sun.COM)
Date:Mar 20, 2009 9:18:40 pm

Although on a purely logical level, I like the current behavior more because of its symmetry and reasonableness. In a sense, the two mixins Football and Video still *work* in spite of the conflict. Had the compiler behaved as Brian described, *neither* would work.

You think that, but you're heading down the road to reinventing multiple inheritance, and all its weird corner cases (like virtual base classes.)

Here's how to think about it. Interfaces impose a contract on their implementors -- implementors *must* have these function members. Mixins extend that to include vars -- implementors of mixins *must* have these var members too. But just as when you implement multiple interfaces, there are not two copies of each function in their intersection, the same is true for their state.

This *does* mean that certain combinations of mixins, or mixins and classes, may be incompatible.

Another question I had regards the additive nature of on replace triggers on such conflicting vars. Should the on replace trigger for Video.count fire? It did fire in the current implementation.

Don't forget that the current implementation is brand new and likely to have bugs. It was just committed for the first time a week ago!