[swift-evolution] [Draft] Mixins

[Trent Nadeau]

In the proposal, I would recommend stressing how this both subsumes
abstract classes and allows similar functionality on value types.

I would also recommend adding a more realistic mixin example such as
logging, where structs and classes want logging functionality but are not
or can't be LoggingObjects. This would show how it gives code reuse without
inheritance and how it would be better than abstract classes.

On Sun, Feb 28, 2016 at 11:43 AM, Антон Жилин <swift-evolution at swift.org>
wrote:

> 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
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160228/26d0735a/attachment.html>