Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The quick answer is: no, there is no way to have the compiler enforce the method signature of a method selector that is provided via a <code>SEL</code> argument.</p> <p>One of the strengths of Objective-C is that it is weakly-typed language, which allows for a lot more dynamic behaviour. Of course, this comes at the cost of compile-time type safety.</p> <p>In order to do what (I think) you want, the best approach is to use delegates. Cocoa uses delegates to allow another class to implement "callback"-type methods. Here is how it might look:</p> <blockquote> <p><strong>FooController.h</strong></p> </blockquote> <pre><code>@protocol FooControllerDelegate @required: - (void)handleData:(NSData *)data forFoo:(FooController *)foo; @end @interface FooController : NSObject { id &lt;FooControllerDelegate&gt; * delegate; } @property (assign) id &lt;FooControllerDelegate&gt; * delegate; - (void)doStuff; @end </code></pre> <blockquote> <p><strong>FooController.m</strong></p> </blockquote> <pre><code>@interface FooController (delegateCalls) - (void)handleData:(NSData *)data; @end @implementation FooController @synthesize delegate; - (id)init { if ((self = [super init]) == nil) { return nil; } delegate = nil; ... return self; } - (void)doStuff { ... [self handleData:data]; } - (void)handleData:(NSData *)data { if (delegate != nil) { [delegate handleData:data forFoo:self]; } else { return; // or throw an error // or handle it yourself } } @end </code></pre> <p>Using the <code>@required</code> keyword in your delegate protocol will prevent you from assigning a delegate to a <code>FooController</code> that does not implement the method exactly as described in the protocol. Attempting to provide a delegate that does not match the <code>@required</code> protocol method will result in a compiler error.</p> <p>Here is how you would create a delegate class to work with the above code:</p> <pre><code>@interface MyFooHandler &lt;FooControllerDelegate&gt; : NSObject { } - (void)handleData:(NSData *)data forFoo:(FooController *)foo; @end @implementation MyFooHandler - (void)handleData:(NSData *)data forFoo:(FooController *)foo { // do something here } @end </code></pre> <p>And here is how you would use everything:</p> <pre><code>FooController * foo = [[FooController alloc] init]; MyFooHandler * fooHandler = [[MyFooHandler alloc] init]; ... [foo setDelegate:fooHandler]; // this would cause a compiler error if fooHandler // did not implement the protocol properly ... [foo doStuff]; // this will call the delegate method on fooHandler ... [fooHandler release]; [foo release]; </code></pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COThank you. This seems to be the way to go in objective c (I use this approach for retrieving results from Subviews). Is a common pattern in cocoa. Much code to just delegate the results of few asynchronous actions to specific methods. I don't like switch statements. They are a capitulation in face of OOP. ;) When there are many actions to handle one must have a god-method responding to all the action objects.
      singulars
    2. COI share your sentiment about switch statements, but I'm not quite sure how it applies to Objective-C development. I have written a large desktop app in Cocoa, and managed to avoid the kind of non-OO programming that you describe. If you find yourself needing a large number of switch statements or god-methods, you may be approaching something from the wrong angle.
      singulars
    3. COYes you are right. I'm now rethinking what I do before things become complicated. ;) I have a abstract Action class and a couple of implementations derived from it. All the actions read data from different places in the "wild world web" and map the results to data objects with different types (Message, Person etc.) All actions are invoked within the same controller. The controller has to respond to each action in a different way. The idea was to delegate the results to different methods within the controller using a selector as argument to the init-Method of the action implementation.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload