[swift-evolution] [Draft] Mixins

[James Campbell]

I think the easier solution is to allow for a default implementation to be
written for a protocol inside of the protocol itself.

*___________________________________*

*James⎥Head of Trolls*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Sat, Feb 27, 2016 at 4:26 PM, Radosław Pietruszewski <
swift-evolution at swift.org> wrote:

> Makes sense to me, and mixins are different enough conceptually from most
> protocols that having a separate keyword (or, more practically, a modifier
> keyword, like `mixin protocol`) might be desirable anyway.
>
> The fact that protocols already come in two flavors — those that can act
> as types, and those that have associated types and therefore can only be
> used as generic constraints — sometimes feels confusing to me. Adding a
> third kind without any differentiation might not be a good idea.
>
> — Radek
>
> On 27 Feb 2016, at 17:17, Trent Nadeau <tanadeau at gmail.com> wrote:
>
> One limitation for "mixin" protocols would be that they can't be
> retroactively modeled, e.g. by having an extension for that protocol on a
> type outside of its file of definition. Allowing this would make the size
> of structs and classes unknowable to the compiler as an extension in
> another library could change the size of all instances.
>
> That limitation is restrictive enough that having a special type of
> protocol and an associated keyword ("mixin") would probably be beneficial.
> The compiler could then easily check the intent of the protocol and ensure
> that a library doesn't break existing extensions just by adding a stored
> property. Only mixin protocols would have this capability.
>
> On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski <
> swift-evolution at swift.org> wrote:
>
>> This is compelling to me.
>>
>> I haven’t put enough thought into it to make up my mind about it, but a
>> mixin system would solve a problem I’m currently struggling with.
>>
>> I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m
>> trying to reduce duplication between the codebases. The problem is, there
>> are things that aren’t easy to completely encapsulate into a separate,
>> universal class — things that have bits and pieces in common, but different
>> overall shape.
>>
>> Perhaps I should encapsulate them anyway, add a level of indirection,
>> inject dependencies… But a mixin is an abstraction that would allow me to
>> extract common parts in an easier way.
>>
>> — Radek
>>
>> On 27 Feb 2016, at 10: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
>>
>>
>
>
> --
> Trent Nadeau
>
>
>
> _______________________________________________
> 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/d8a9ebf8/attachment.html>