DelegateProxy revamp

[andersio]

1. Methods would now be automatically implemented. Subclassing is no longer necessary.

2. DelegateProxy can now be constructed through NSObject.reactive.proxy(forKey:).

3. Fixed a memory leak due to the use of forwardingTarget(for:) as the fast path of delegate call forwarding.

4. More DelegateProxy test cases.

Usage

extension Reactive where Base: UITableView {
    var proxy: DelegateProxy<UITableViewDelegate> {
        return proxy(forKey: #keyPath(UITableView.delegate))
    }
}

To-do

• Evaluate the behaviour of protocols with non-void-returning required methods.
• Documentations and Implementation Notes.
• Share implementation with method Interception.

[dmcrodrigues]

@mdiep any chance of moving this forward?

[mdiep]

Somehow I missed this. I just got back from vacation, but I'll this to my list. Want to fix up the conflicts, @andersio?

[andersio]

Sure. Will do it this week.

[mdiep]

Should this be public? Or should we only expose the proxy method below?

If this is public, should we inline the properties from DelegateProxyConfiguration in the init?

[andersio]

The initialiser is meant to be exposed, while the details of the configuration are meant to be hidden. This is to satisfy the compiler constraint of instantiating instances from the metatype of the non-final DelegateProxy, which requires init(DelegateProxyConfiguration) to be always present in all subclasses, so that the instantiation via the metatype always succeeds.

[mdiep]

Why is DelegateProxy non-final?

[andersio]

CI build might be affected by #3642.

[mdiep]

Why can't DelegateProxy be final?

[andersio]

#3467 (comment)

But if you still think it is more sensible for us to start with final, I am fine with that.
Apparently I've already made it non-open. I guess the intention of not marking it as final is to avoid any library evolution implication — undoing final is not a permitted change.

Most importantly, this entity primarily interacts with ObjC which final has no effect, and being public already prohibits subclassing.

[mdiep]

But if we made it final, then we could make this method private? That seems worth doing

[andersio]

Yep.

[andersio]

In any case I think intercepting non-void returning methods is probably very niche, and a rather dangerous zone to walk into with little return. So closing it should be fine.

[mdiep]

Let's get this merged before doing a new release for ReactiveSwift 5.

The only outstanding question from me is this. If we can't do that, you're good to merge.

[mdiep]

The tests need to be updated to not inherit from DelegateProxy now that it's final.

[mdiep]

@andersio I'd like to release ReactiveCocoa 9.0. Still want to get this in?

[mdiep]

It looks like there may still be some legitimate test failures?