> On Apr 26, 2016, at 3:33 AM, James Froggatt <conducta...@ntlworld.com> wrote:
>
> Fair enough. Upon reflection, I think my real issue is somewhat different to
> what I suggested previously.
>
> I wasn't intending to suggest such a thing would be practical, just that it
> would be a decent alternative to optional protocol requirements. The
> alternative given in the proposal seems to be more of a way to remove
> optional protocol requirements on the surface, while actually helping to make
> them a native feature, if you see what I mean. It's not a realistic
> alternative - it's a worse syntax for the exact same thing, which also comes
> with awful side-effects for Swift as a whole. No-one would ever seriously
> consider this as an alternative, yet it's listed as under the heading
> ‘Alternatives Considered’.
If you follow the swift-evolution discussion links in the proposal, you’ll note
that a number of people have proposed exactly what is listed in “Alternatives
Considered”. The only truly wacky idea in there is my caller-side default
implementations idea, which I covered simply because it was my last stab at
eliminating optional requirements before giving up and sequestering them
permanently behind “@objc”.
>
> You say the arguments given against optional closure properties are strong,
> but I don't they would be nearly as relevant to the case I suggested. By
> making them properties of the table view, the tableView parameter would be
> eliminated, meaning the property names could be unique.
>
> EG:
> var numberOfRows: (inSection: Int) -> Int
> var cellForRow:: (at: NSIndexPath) -> UITableViewCell
> var moveRow: (from: NSIndexPath, to: NSIndexPath)
>
> This removes the need to add the mentioned workarounds, since a function
> could be assigned to the closure property just as easily as an inline
> closure. I feel this is much more worthy of being considered as an
> alternative. The idea of these proposals is to document why we do things, so
> at least for someone wondering why we require all this @objc syntax rather
> than support optional protocol requirements natively, this would actually
> present them with a viable alternative which could be applied in their APIs.
Doing this implies creating a potentially large number of stored closure
properties, which is not as storage-efficient as storing a single delegate
reference. Moreover, it makes it harder to set up your customization points:
instead of implementing one protocol, you’re writing assignments into some
number of stored closure properties. Imaging trying to change the delegate to
some other delegate temporarily: you would have to manually store each of the
closures into some local structure and introduce your own, except that you
can’t get them all because some new version of the platform would add new
stored closure properties. Finally, Cocoa just doesn’t work like this, so you
would require some massive re-architecture to get there. I don’t see how this
is a better design.
- Doug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
