[swift-evolution] Properties on Default Protocol Implementations

[Wallacy]

Also, FWIW:

Another example using Dave's presentation:

extension Renderer where Self:CGContext { // same as extension CGContext :
Renderer in this case
   * var defaultDashPhase:CGFloat = 0.0*
*    var defaultDashLengths:[CGFloat] = [10.0, 4.0]*

    func moveTo(position: CGPoint) {
        CGContextMoveToPoint(self, position.x, position.y)
    }
    func lineTo(position: CGPoint) {
        CGContextAddLineToPoint(self, position.x, position.y)
    }
    *func dashedLineTo(position: CGPoint) {*
*
CGContextSetLineDash(self,defaultDashPhase,defaultDashLengths,defaultDashLengths.count);*
*        CGContextAddLineToPoint(self, position.x, position.y)*
*    }*
    func arcAt(center: CGPoint, radius: CGFloat, startAngle: CGFloat,
endAngle: CGFloat) {
        let arc = CGPathCreateMutable()
        CGPathAddArc(arc, nil, center.x, center.y, radius, startAngle,
endAngle, true)
        CGContextAddPath(self, arc)
    }
}

We can make more "customizable" extensions, good... And for other "kind" of
Renderer we can use other variables (for that kind), fine.

It's too much magic i know, but i can see some problems be solved using
this construct. But i don't know how to make this more explicit on protocol
declaration, or just leave in that way, like the other functions.




Em ter, 12 de jan de 2016 às 13:32, Wallacy <wallacyf at gmail.com> escreveu:

> Yes, currently is hard to "know for sure" if you need for implement all
> requirements of the protocol. Usually I wait for compile to tell me.
>
> Anyway, i think the protocols is more useful to model behaviour, and
> default implementation help with that. Its like multiple inheritance
> without the hard part.
>
> So I'm very concerned about putting "a lot of stuffs" on protocols, and
> bring the bad parts of multiple heritage.
>
> Although my proposal, I believe protocols need to be extremely simple, and
> easy to use. And i'm really think the storage properties can help with
> that. I'm worried about the idea of people using/modeling protocols just as
> concrete types.
>
> If this idea go ahead, it may be an opportunity to bring some clarity to
> the current scenario, but also prevent future abuses.
>
> The main problem is (to me): What is really a Protocol Oriented
> Programing? I Saw Dave Abrahams presentations a few times, but the whole
> idea is not 100% clear. So it's hard to think of a design to help this
> concept.
>
>
> Em ter, 12 de jan de 2016 às 05:11, Brent Royal-Gordon via swift-evolution
> <swift-evolution at swift.org> escreveu:
>
>> > An automatic approach brings hesitation to me, because I don’t want it
>> to be the difference between:
>> >
>> > protocol P {
>> >  var x : Int { get }
>> > }
>> >
>> > and:
>> >
>> > protocol P {
>> >  var x : Int
>> > }
>> >
>> > Did I want a PwS there, or did I just forget {get/set}?
>>
>> If we're going to start adding concrete things to protocols—not just
>> stored properties, but (drawing on other proposals) perhaps also default
>> implementations, final members, factory initializers, etc.—perhaps we
>> should start marking the things that *aren't* concrete with `required`.
>>
>> Currently:
>>
>>         public protocol Strideable : Comparable, _Strideable {
>>             associatedtype Stride : SignedNumberType
>>             @warn_unused_result
>>             public func distanceTo(other: Self) -> Self.Stride
>>             @warn_unused_result
>>             public func advancedBy(n: Self.Stride) -> Self
>>         }
>>
>>         extension Strideable {
>>             @warn_unused_result
>>             public func stride(to end: Self, by stride: Self.Stride) ->
>> StrideTo<Self> {
>>                 /* implementation here */
>>             }
>>         }
>>
>>         extension Strideable {
>>             @warn_unused_result
>>             public func stride(through end: Self, by stride: Self.Stride)
>> -> StrideThrough<Self> {
>>                 /* implementation here */
>>             }
>>         }
>>
>> Future:
>>
>>         public protocol Strideable : Comparable, _Strideable {
>>             associatedtype Stride : SignedNumberType
>>             @warn_unused_result
>>             required public func distanceTo(other: Self) -> Self.Stride
>>             @warn_unused_result
>>             required public func advancedBy(n: Self.Stride) -> Self
>>
>>             @warn_unused_result
>>             final public func stride(to end: Self, by stride:
>> Self.Stride) -> StrideTo<Self> {
>>                 /* implementation here */
>>             }
>>
>>             @warn_unused_result
>>             final public func stride(through end: Self, by stride:
>> Self.Stride) -> StrideThrough<Self> {
>>                 /* implementation here */
>>             }
>>         }
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> 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/20160112/a6acca08/attachment.html>