[swift-evolution] [Draft] Mixins

Patrick R. Gili gili.patrick.r at gili-labs.com
Sun Feb 28 07:47:54 CST 2016


I see many problems with this proposal:

- The proposal doesn't provide a compelling example to change Swift.

- The proposal doesn't provide much detail. It glosses over the general concept.

- Protocols define a statement of conformance, not behavior. Adding instance variables and non-default methods is outside the scope of a protocol.

- However, the proposal does describe something closer to a mix-in. Given my experience with Ruby and mix-ins, I really can't support the notion of mix-ins in Swift. Instance variables defined by a mix-in cause many problems, and hence I don't see this proposal aligned with the direction of Swift.

-Patrick

Sent from my iPad Pro

> On Feb 27, 2016, at 8:10 AM, Антон Жилин via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I agree that adding those features to protocols is simpler. I switched the main suggestion and the alternative.
> 
> 2016-02-27 15:03 GMT+03:00 Haravikk <swift-evolution at haravikk.me>:
>> Very interesting alternative!
>> 
>> I think my preferred implementation is to just add these capabilities to protocols directly, as I guess I just don’t see why we need to introduce a separate mixin type. Providing implementation directly within a protocol is definitely something I’d like in general; while extensions can be a nice way to structure complex protocols and types, sometimes simple cases just don’t really need them IMO, so that’d be nice as a general capability, not just for mixins.
>> 
>>> On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 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
>>> 
>>> 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
> 
> _______________________________________________
> 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/20160228/f4091c39/attachment.html>


More information about the swift-evolution mailing list