[swift-evolution] [Draft] Mixins

Mon Feb 29 17:28:44 CST 2016

First, thank you very much for starting this discussion!

I have been thinking of an alternate strategy using traits, partially based on http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf <http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf> .

In my alternate strategy, you would have trait objects which behave similar to value types. They would expose methods/properties, can conform to protocols, and can also require other properties/methods via delegate protocols. When composed by an outer object, the properties/methods and protocol conformance can be either directly addressed or mapped (via some language syntax or via explicit wrapping functions) to the outer object’s usage contract as new properties/methods/protocol conformance.

The trait objects do not hold state, although the delegate protocols they require for usage can provide said state.

Similar to property behaviors, one could make a naive implementation today via generic wrappers. However, this would require duplicated state to provide the delegate protocols where needed, as well as complexity of use and memory duplication when those implementations are backed by value types. Thus, this feature falls into a similar camp of needing compiler support for optimal memory use/performance. While traits behave as if they are separate objects, they should not be treated as such and fall closer into the realm of macros.

You would not include these traits via the inheritance/implementation mechanism - they would not participate in an object’s superclass hierarchy or protocol conformance. Instead they act closer to ‘let’ properties.

Language syntax would be used to selectively map methods, properties, and full protocol conformance from a trait to the externally accessible interface of a composing object. Likewise, you can map properties/methods/protocol conformance of your object to fulfill the delegate protocol requirements of a trait. Unmapped features of a trait are not visible outside an object.

Conflicts between multiple traits just prevent the mapping syntax. However, you should be able to resolve this by writing your own implementations for the conflicting traits on the composing object.

Finally, as indicated before a trait can require multiple delegate protocols, such as how UITableView has both UI behavior and data delegate interfaces. “Mixin” behavior could come from having an object which has a default implementation of that data protocol, and mapping to a property holding an instance of that object within the composing type.

-DW

> On Feb 29, 2016, at 11:51 AM, Антон Жилин 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.
> 
> 3. `mixin` vs `trait`. Please read Wiki or any other source and tell what is a better name.
> 
> 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?
> 
> 5. Are you happy with Initializers section?
> 
> 6. Can motivation examples be improved?
> 
> 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/595806a9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160229/595806a9/attachment.sig>