[swift-dev] Is there an underlying reason why optional protocol requirements need @objc?

[Shawn Erickson]

(Sorry I hate top posting but fighting with Google inbox to avoid it)

In delegation patterns it can be very helpful in terms of optimization
(performance and memory) if the delegator can interrogate a delegate to
know if certain delegation points are needed or not. I have code that has
done this interrogation at delegate registration allowing potentially
complex code paths and/or state maintenance to be avoided. It also could do
impl caching to improve dispatch (did not support after registration
"reconfiguring" delegates in this model purposely).

Under objective-c leveraging optional protocol methods and runtime checks
for responds to those was one built-in way for that. It also could add
boilerplate code to check before dispatch that was potentially error prone
and cumbersome. ...hence why I often did the check and configuration at
registration in my code often avoiding peppering code with dispatch checks.

Anyway not attempting to state anything for against this question about
optional requirements in swift protocols. ...a handful of reasonable
patterns exist in swift that allows one to achieve the same thing in safer
and likely more performant ways.

-Shawn


On Fri, Mar 4, 2016 at 9:38 AM Dave Abrahams <dabrahams at apple.com> wrote:

>
> on Fri Mar 04 2016, Shawn Erickson <shawnce-AT-gmail.com> wrote:
>
> > Well one missed aspect is that the delegator can test if the delegate
> > responds to the method and modify its logic to adjust to the reality
> (which
> > could have reasonable optimization hanging off it). If you depend on
> > default no-op you don't get that ability (at least as "easily"). ...it of
> > course is intertwined with the runtime capabilities of objective-c.
>
> All that testing puts too much burden on the client, IMO.  It's much
> better to provide customization points with default behaviors that work
> sensibly when not overridden.
>
> >
> > On Fri, Mar 4, 2016 at 9:16 AM Erica Sadun via swift-dev <
> > swift-dev at swift.org> wrote:
> >
> >>
> >> > On Mar 4, 2016, at 9:25 AM, Dave Abrahams via swift-dev <
> >> swift-dev at swift.org> wrote:
> >> >
> >> >
> >> > on Fri Mar 04 2016, Simon Pilkington <swift-dev-AT-swift.org> wrote:
> >> >
> >> >> This seems like a strange/unrelated restriction on what is quite a
> >> useful feature.
> >> >
> >> > ...or an abomination.  What sense does “optional requirement” make,
> >> > after all?!
> >> >
> >>
> >> However oxymoronic,  I kind of get the point. If you want default no-op
> >> behaviors, with
> >> the option to override, which is what optional Objective-C requirements
> >> really are, just
> >> create protocol extensions.
> >>
> >> extension MyProtocol {
> >>    func optionalMember() {} // nothing to do
> >> }
> >>
> >> This guarantees that the member exists, can be called by all consumers,
> >> but that there's a
> >> default in place that frees the conforming type from actually having to
> >> implement anything
> >> unless it really wants to.
> >>
> >> -- E
> >>
> >>
> >> _______________________________________________
> >> swift-dev mailing list
> >> swift-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-dev
> >>
>
> --
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160304/d8e480fc/attachment.html>