ReactiveCocoa/ReactiveCocoa — pull request #931 by woolsweater (2013-11-10 07:08:31+00:00)
Title: Allow binding a signal other than command.enabled to the control's enabled

Using NSControl+RACCommandSupport, it's not currently possible to set up a connection to an object such that it has access to the control's command signal in its initialization while the control's `enabled` is bound to a signal coming from that same object:

MyController *controller;

[aButton setRac_command:
[[RACCommand alloc] initWithSignalBlock:^RACSignal *(NSButton * _) {
return [RACSignal return:@YES];
}]];

RACSignal * buttonSignal = [[aButton rac_command] executionSignals];

controller = [[MyController alloc] initWithButtonSignal:buttonSignal];

// Does not exist
[aButton <#bind enabled to#>:[controller aSignal]];

The alternative

// Set up signal as best as possible without button
MyController *controller = [MyController new];

[aButton setRac_command:
[[RACCommand alloc] initWithEnabled:[controller aSignal]
signalBlock:^RACSignal *(NSButton * _) {
return [RACSignal return:@YES];
}]];

[controller setButtonSignal:[[aButton rac_command] executionSignals]];

necessitates a potentially awkward (certainly repetitive) re-wiring of the controller's already-created signal in `setButtonSignal:`

I propose adding a single method to `NSControl+RACCommandSupport` to allow the control's `enabled` to be rebound to any signal after the command is set. This pull request implements that solution, and includes a test for the new functionality.

The change is very minor; the existing code binding the control's `enabled` in `setRac_command:` was simply moved to its own method.

If you think it's necessary that the command's `enabled` be involved in the control's status, my alternate proposal is to allow setting a "secondary" signal whose values will be ANDed with `command.enabled`. I have that code in a branch NSControl-mergeEnabledBindingSignals in my fork of RAC and can submit another pull request.