[swift-evolution] [Draft] Mixins
Антон Жилин
antonyzhilin at gmail.com
Sun Feb 28 10:43:06 CST 2016
I now have 4 votes "for" separating this new entity from protocols.
Proposal changed.
I tried to solve the aforementioned issues except the last one, which
essentially compares mixins to abstract classes.
More "bug reports" welcome!
2016-02-28 16:47 GMT+03:00 Patrick R. Gili <gili.patrick.r at gili-labs.com>:
> 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/18417bb4/attachment.html>
More information about the swift-evolution
mailing list