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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
