Sent from my iPad
> On May 9, 2016, at 5:53 PM, Rod Brown <[email protected]> wrote:
>
> Response inline
>
>
>> On 10 May 2016, at 8:28 AM, Matthew Johnson <[email protected]> wrote:
>>
>>
>>> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> The problem then becomes how do we model such optimizations in Swift.
>>> Default methods, while useful for plenty of cases, don't work with this
>>> system as there is no runtime check to see if the object actually
>>> implements that method. The optimizations don't just check the existence
>>> for a default value - they actually lead to different code paths.
>>>
>>> Can this be done? Absolutely. Either by segregating the protocols as you
>>> mentioned, or by adding some other way to cue the optimized sizing path.
>>> That said, it's certainly not as clean as the Objective-C design.
>>
>> Clean is in the eye of the beholder. I definitely don’t think the
>> Objective-C design feels right in Swift.
>>
>> There have been times where I implemented delegates where the row height
>> strategy was decided at initialization time. In Objective-C I was able to
>> do this by implementing respondsToSelector. That feels a bit dirty, but it
>> works. In pure Swift there is no way to do that at all.
>>
>> Swift allows a delegate protocol design to take a position on whether the
>> initialization-time decision is supported or is a code smell that should be
>> disallowed. The approach of segregated protocols disallows it. Alternative
>> mechanisms such as a boolean getter allow for it.
>
> I agree with this completely. By clean I was referring to the fact it's more
> concise, not that it's a good fit for the language. I don't think we should
> adopt this feature in Swift without seriously considering the implications
> because the nature of Swift's protocols is very different to that of Obj-C. I
> suspect there are better ways to model this behavior without breaking the
> philosophical underpinnings of Swift Protocols.
>
>>>
>>> In general, I think default implementations fix a lot of the simpler cases
>>> surrounding optional methods and actually simplify other implementations
>>> (no runtime checks!). But they don't solve the real value proposition that
>>> the fully dynamic Objective-C design provided in this feature.
>>>
>>> Do I support default implementations on protocols as a concept? Definitely.
>>> But I don't think we should kid ourselves that this solves anything apart
>>> from the simpler cases.
>>
>> I agree with this. I think we should study the more complex cases and
>> establish guidelines around idiomatic patterns for them in Swift. This may
>> even result in proposals for language enhancements to support the idioms we
>> want to see in Swift. But I’m glad to see “optional requirements” going
>> away.
>>
>> -Matthew
>
> I don't think they're going away at this time, so much as we are clarifying
> what is already the case: they are an Obj-C only feature, and aren't
> supported in Swift standalone. They make sense and will continue to make
> sense in an Obj-C world, but they're not a foundational element of Swift.
Agree. I said going away with an indefinite, likely long time frame in mind.
:)
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
