[swift-evolution] [Draft] Mixins

[Антон Жилин]

Ah, I see now. The proposal started with `mixin` keyword being primary and
extending `protocol` in alternatives. Then I swapped then. Maybe I should
swap them again :P

I tend to agree with your argumentation.
Currently proposed methods in protocol extensions act as default methods
(no class inheritance support, if you are aware of that issue), but in
protocol body - as function methods. If we add `mixin protocol`s, then
behaviour of that methods will be consistent.
And do we need associated types (read generics) for mixins?

I also had a proposal for separating protocols and interfaces, but it got
turned down because of proposal for existentials, which I have not heard of
for long. Here it is:
https://github.com/Anton3/swift-evolution/blob/master/proposals/0000-introducing-interfaces.md

If both proposals got accepted, we would have protocols, interfaces and
mixins. Protocols would have associated types, interfaces - dynamism,
mixins - state.

2016-02-27 19:32 GMT+03:00 Trent Nadeau <tanadeau at gmail.com>:

> I don't mean stored properties declared in extensions. I'm talking about
> conforming to a "mixin" protocol via an extension in another file. For
> example:
>
> // Foo.swift
> struct Blah {
>     var x : Int
> }
>
> // Mixins.swift
> protocol MyMixin {
>     var y : Double // mixin having a stored property
> }
>
> // Bar.swift
> extension Blah : MyMixin {} // this changes the size of all instances of
> Blah in the program
>
> On Sat, Feb 27, 2016 at 11:26 AM, Антон Жилин <antonyzhilin at gmail.com>
> wrote:
>
>> In my current proposal, stored properties of protocols have no abilities
>> beyond that of structs. They cannot be declared in extensions, that's
>> intentional. Could you give an example where such decoupled definition
>> would be better than multiple mixins, for example?
>>
>> 2016-02-27 19:17 GMT+03:00 Trent Nadeau <tanadeau at gmail.com>:
>>
>>> 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
>>>
>>
>>
>
>
> --
> Trent Nadeau
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/4a7a25ec/attachment.html>