[swift-evolution] [Draft] Mixins

[Trent Nadeau]

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/4d890ac7/attachment.html>