[swift-evolution] [Draft] Mixins

[Howard Lovatt]

In line below.

  -- Howard.

On 1 March 2016 at 05:51, Антон Жилин <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
>
> 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?
>

I would prefer generics so that they work seamlessly with structs and
classes that use generics without having to use type constraints via where
clauses

>
> 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.
>

trait, not trait protocol - see below

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

trait since the proposal is very close to "Traits: Composable Units of
Behaviour", by Nathanael Scha ̈rli, Ste ́phane Ducasse, Oscar Nierstrasz,
and Andrew P. Black, which is the paper that 1st proposed traits.


>
> 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?
>

No protocols are good for that. Keep it simple at 1st, can always be added
latter.

>
> 5. Are you happy with Initializers section?
>

Yes

>
> 6. Can motivation examples be improved?
>

How about adding implementing CustomStringConvertable and Equatable, e.g.:

mixing Shape: CustomStringConvertable, Equatable {

var center: CGPoint = CGPoint.zero

var bounds: CGSize { get } // Note: not implemented

var description: String { return "Shape(center: x: \(center), bounds:
\(bounds))"

}

func ==(lhs: Shape, rhs: Shape) -> Bool {

return lhs.center == rhs.center && lhs.bounds == rhs.bounds

}


mixing Line: CustomStringConvertable, Equatable {

var color = UIColor.blackColor()

var width = 1
var description: String { return "Line(color: x: \(color), width: \(width))"

}

func ==(lhs: Line, rhs: Line) -> Bool {

return lhs.color == rhs.color && lhs.width == rhs.width

}


struct Rectangle: Shape, Line {

var size: CGSize

override var bounds: CGSize { return size } // Implements Shape.bounds
override var description: String { return "Rectangle(shape: x:
\(Shape.super.description), Line: \(Line.super.description))"

}

func ==(lhs: Rectangle, rhs: Rectangle) -> Bool {

return (lhs as Shape) == (rhs as Shape) && (lhs as Line) == (rhs as Line)

}


Extra possible improvement. Add a section about resolving a conflict
arising from multiple definitions. My suggestion is to mimic the `A.super`
syntax used for calling initializers:

 mixin A { var x = 0 }

mixin B { var x = 1 }
mixin C : A, B { override var x = A.super.x }  // OK, conflict
resolved because x overridden


The addition of the `A.super.x` syntax isn't strictly necessary since you
could write `(self as A).x`, but I prefer `A.super.x`.


> 2016-02-29 4:07 GMT+03:00 Step C <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>
>> 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> 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>
>> wrote:
>>
>>> Link to the proposal:
>>> https://gist.github.com/Anton3/f0550922c1be0fc5447c
>>>
>>> 2016-02-29 0:56 GMT+03:00 Step C <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> 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
>>>> > 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/20160301/4c328c0b/attachment.html>