> On Apr 25, 2016, at 12:18 PM, James Froggatt via swift-evolution
> <[email protected]> wrote:
>
> Eliminating optional protocol requirements is fine by me. The proposal
> mentions ‘correcting’ the optional protocol requirement pattern by changing
> the methods to optional closure properties, but my feeling is that this
> ‘solution’ just acts to continue and perhaps encourage the anti-pattern
> established by ObjC. I think a native Swift design would be much better off
> using optional closure properties on the table view itself.
>
> A common theme in these ObjC optional protocol requirements is the first
> parameter being an instance whichever class ‘requires’ the method. Yet on the
> rare occasion of the instance potentially having more than one value, the
> implementation for each instance is often so different that my first action
> will be to add a switch between the possible instances (which, of course,
> means having those components available as IBOutlet properties anyway).
>
> I suggest a much better solution to optional protocol requirements in Swift
> is the creation of wrappers for UIKit components. These would implement the
> protocol requirements, and expose optional closure properties for their their
> public API. Making them properties makes it far clearer that the behaviour of
> the container will change if a value is provided, and would remove the
> persistent need to apply @objc to any Swift types dealing with UIKit. I
> understand this would be a manual task, but I just don't think there is a
> good automatic solution to this problem.
There are ~800 optional requirements in the iOS SDK and ~1000 in the OS X SDK.
That too large a manual task to accomplish.
Also, I think the arguments in the proposal against the
optional-closure-properties approach are fairly strong: it doesn’t seem like a
good way to model Objective-C optional requirements.
- Doug
>
> ------------ Begin Message ------------
> Group: gmane.comp.lang.swift.evolution
> MsgID: <[email protected]>
>
> Hello Swift community,
>
> The review of "SE-0070: Make Optional Requirements Objective-C only" begins
> now and runs through May 2. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review
> manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or
> an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
> � �
>
> ------------- End Message -------------
>
>
>
> From James F
>
>
> From James F
> _______________________________________________
> 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
