> Am 31.03.2016 um 17:18 schrieb Sean Heber <[email protected]>:
>
> Some ideas I was thinking about for optional protocol functions was you’d
> declare it like this:
>
> protocol UIGestureRecognizerDelegate {
> optional func gestureRecognizerShouldBegin(gestureRecognizer:
> UIGestureRecognizer) -> Bool = true
> }
Why not just the following
import Foundation
// optional delegate method
protocol UIGestureRecognizerDelegate {
var gestureRecognizerShouldBegin: ((gestureRecognizer: UIGestureRecognizer)
-> Bool)? { get }
}
extension UIGestureRecognizerDelegate {
var gestureRecognizerShouldBegin: ((gestureRecognizer: UIGestureRecognizer)
-> Bool)? {
return nil
}
}
class UIGestureRecognizer {
var delegate: UIGestureRecognizerDelegate?
func callDelegate() {
if let gestureRecognizerShouldBegin =
delegate?.gestureRecognizerShouldBegin {
gestureRecognizerShouldBegin(gestureRecognizer: self)
}
}
}
// implementing a delegate:
struct MyDelegate : UIGestureRecognizerDelegate {
var gestureRecognizerShouldBegin: ((gestureRecognizer: UIGestureRecognizer)
-> Bool)? {
return { (gestureRecognizer: UIGestureRecognizer) -> Bool in
return true
}
}
}
struct MyOtherDelegate : UIGestureRecognizerDelegate { }
This captures the idea of optional methods as used in Objective-C quite nicely
IMO. And it already works without needing a new language feature.
If/when Swift gains the ability to declare default implementations within a
protocol instead of needing an extension the boilerplate of having to repeat
everything in the extension would drop away.
> If you put “optional” there, the compiler would auto-generate an empty
> function in a protocol extension in your module as if you had specified one
> yourself. If the function has a return value, you would be required to
> specify the default return value in the protocol which provides automatic
> documentation of the default, too. (It would be an error to have an optional
> function with a return value that doesn’t have a default value specified in
> the protocol.) (I am not currently in favor of supplying a default
> implementation body inside of a protocol as has been discussed some
> previously.)
I do not understand why an optional method should require a default value.
That’s not how optional methods work in Objective-C where the caller will ask
whether the method is implemented and calls it or does something else. With a
default value it would be much more difficult to do something different if the
method is not implemented.
Actually with a default value the method would just be a normal method which
has not been overridden, there would be nothing optional about it anymore.
-Thorsten
>
> If you provide a default implementation of an optional protocol function in a
> protocol extension in the same module as the protocol itself is declared in,
> it would be an error and you’d have to make the function non-optional or get
> rid of your conflicting protocol extension implementation. If the protocol
> was declared in a different module, then that restriction would be lifted
> since presumably you’re providing a default implementation via protocol
> extension on purpose.
>
> l8r
> Sean
>
>
>> On Mar 31, 2016, at 1:34 AM, Thorsten Seitz via swift-evolution
>> <[email protected]> wrote:
>>
>> Just a thought: optional methods could be modeled by methods in a protocol
>> that return optional closures.
>>
>> -Thorsten
>>
>>
>> Am 31. März 2016 um 04:42 schrieb Andrey Tarantsov via swift-evolution
>> <[email protected]>:
>>
>>> I'm missing those optional methods too, but protocol extensions sound like
>>> a better solution for this.
>>>
>>> (For those suggesting a separate protocol, consider UITableView. How many
>>> protocols would it take to model all the optional delegate methods as
>>> separate protocols? Certainly more than 10, perhaps a few dozen.)
>>>
>>> I would welcome a standardized way to document the methods as
>>> optional-to-implement, though, beyond just requiring a protocol extension.
>>> My ideal option would be to allow the optional keyword and change it to
>>> simply require a default implementation in a protocol extension.
>>>
>>> If we don't want a language change, then perhaps a conventional doc tag?
>>>
>>> A.
>>>
>>>
>>>> On Mar 30, 2016, at 8:08 PM, Yuval Tal via swift-evolution
>>>> <[email protected]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I find that optional protocol methods to be very useful. However, there is
>>>> a caveat -- it needs to be mapped to @objc. This puts a set of
>>>> limitations, such as: structures cannot be used as parameters as it does
>>>> not map to objective-c. What do you think about removing the requirement
>>>> of using @objc and allow to create optional methods without these
>>>> limitations?
>>>>
>>>> Thank you,
>>>>
>>>> -Yuval
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
