[swift-evolution] [Draft] Mixins

[Jim Driscoll]

Regarding multiple inheritance of protocols, it shouldn’t be a huge problem from the developer’s perspective to have multiple values for the same property because you’d have the same expectation as if there had just been multiple assignments: last one wins. The problem I’d see for the example scenario is that the semantics of the property may be completely different, in which case having a value that the protocol doesn’t expect may break it. The only adequate protections for that kind of matter is either preventing declarations of the same property across multiple included protocols or giving them their own namespaces (which would be a problem in itself).

> On 27 Feb 2016, at 20:30, David Scrève via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 	I have already considered adding store properties to protocols before proposing abstract classes, but there are some issues : 
> 
> 1 - If protocols can have stored properties and default method implementation, how do you explain to newby the difference between a class and a protocol ? There is the same problem with Java 8 and interface which make learning to student really painfull….
> In short words, protocol will became a sort of class and no longer a true kind of contract to conform to.
> 
> 2 - What about compatibility with Objective C ?
> 
> 3- more interesting problem : At the moment, multiple inheritance for protocol is allowed. When introducing store property in protocol, you introduce a major issue that C++ have : the diamond problem.
> 
> Example : 
> 
> protocol A {
> 	var value = 34
> } 
> 
> protocol B {
> 	var value = 23
> }
> 
> class myClass : A, B {
>     func init {
>         print("Value  : \(value));
>     }
> }
> 
> What should be print out ? how do you manage access to A.value and B.value ?
> 
> 
>> Some people opposed to Abstract Classes proposal (including myself) have
>> said that mixins could solve the problem better.
>> So I prepaired a proposal draft to add stored properties to protocols. Here
>> it is:
>> https://gist.github.com/Anton3/f0550922c1be0fc5447c <https://gist.github.com/Anton3/f0550922c1be0fc5447c>
>> 
>> P.S. I added a `mixin` keyword in the beginning, but we can opt to just
>> extend protocols, which I mention in "alternatives".
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/eba16568/attachment.html>