[swift-evolution] [Draft] Mixins

[Patrick Gili]

> On Feb 29, 2016, at 1:51 PM, Антон Жилин via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm prepairing to create a pull request, so I moved the proposal from Gist to my fork of swift-evolution.
> Link to the proposal new and hopefully final home:
> https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md <https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md>
> 
> Should I create a pull request right now or wait a bit?
> 
> Some details need to be discussed:
> 
> 1. Do mixins need associated types? Would generics be more appropriate to them?
> 
> 2. `mixin` vs `mixin protocol`. On one hand, `mixin protocol` does not require a keyword.
> On the other hand, as stated in a special section, mixins cannot be used everywhere a protocol can. Protocols, mixins, traits, interfaces are all different entities.

Protocols and mixins address different problems. A protocol defines a statement of conformance. A mixin defines code and/or state to share. Why not allow mixins to conform to protocols?

> 
> 3. `mixin` vs `trait`. Please read Wiki or any other source and tell what is a better name.

Traits typically do not define state. If you want to define state, then you're working with mixins.

> 
> 4. Objective-C interfacing. Do we have to require it now? (I doubt so.) Can we allow mixing-in Swift mixins to Objective-C classes?

Why? This is Swift.

> 
> 5. Are you happy with Initializers section?

IMHO, initializers should only be defined by entities.

> 
> 6. Can motivation examples be improved?

Yes.

7. Need to address name collisions? I love Ruby, but there are many poorly written mixins out there and they quickly become the bane of a developer's existence. What if the name of a mixin qualified the names of the methods and state contained by the mixin?

> 
> 2016-02-29 4:07 GMT+03:00 Step C <schristopher at bignerdranch.com <mailto:schristopher at bignerdranch.com>>:
> Sorry, I understood "that phrase" to mean what I just stated. 
> 
> 
> On Feb 28, 2016, at 8:03 PM, Step C <schristopher at bignerdranch.com <mailto:schristopher at bignerdranch.com>> wrote:
> 
>> I understood him to mean that abstract classes cannot be used for value types, but it would be natural to want that functionality. Mixins would provide that capability for value types as well as classes.
>> 
>> On Feb 28, 2016, at 7:41 PM, Trent Nadeau <tanadeau at gmail.com <mailto:tanadeau at gmail.com>> wrote:
>> 
>>> The quoted portion of the proposal below doesn't make any sense to me. Subclasses can't be value types. Do you mean the structs could have similar functionality?
>>> 
>>> Firstly, only classes can inherit from such abstract classes, while it can be easily seen that some subclasses ofCachingSerializable or SignalSender would naturally have value semantics (be structs, in other words).
>>> 
>>> On Sun, Feb 28, 2016 at 5:03 PM, Антон Жилин <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> Link to the proposal: https://gist.github.com/Anton3/f0550922c1be0fc5447c <https://gist.github.com/Anton3/f0550922c1be0fc5447c>
>>> 
>>> 2016-02-29 0:56 GMT+03:00 Step C <schristopher at bignerdranch.com <mailto:schristopher at bignerdranch.com>>:
>>> It would be helpful if you include the new draft. Or at least a link to it.
>>> 
>>> > On Feb 28, 2016, at 3:30 PM, Антон Жилин via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> >
>>> > I have rewritten almost the whole proposal in the last 10 hours. I encourage everyone interested to reread it and suggest fixes, improvements, as well as new directions for discussion.
>>> > _______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160229/2194b93c/attachment.html>