views:

479

answers:

3

This is a followup to Avoiding @property-itis.

UIWebView has the following property declarations:

@property(nonatomic,readonly,getter=canGoBack) BOOL canGoBack;
@property(nonatomic,readonly,getter=canGoForward) BOOL canGoForward;

UIScrollView has these:

@property(nonatomic) BOOL canCancelContentTouches;

Yet, UIResponder has

- (BOOL)isFirstResponder;
- (BOOL)canBecomeFirstResponder;
- (BOOL)canResignFirstResponder;

Is the UIResponder case one where they should have been declared as properties, but, for whatever reason, were not?

Or is it a case where declaring them as properties was inappropriate? If inappropriate, why?

+1  A: 

My best guess is that UIResponder is meant to match NSResponder, which of course was designed before Objective-C 2.0 introduced properties. Why UIWebView doesn't do the same with regard to WebView, I don't know. I'd expect properties in Cocoa to be a little schizophrenic in this way for some time, and I wouldn't think into it too much when considering your own code.

Marc Charbonneau
I realize that Cocoa (and UIKit, but to a lesser degree because it is newer) is going to be inconsistent for awhile.However, back to the question... if we were designing UIResponder anew, would those three methods better be expressed as properties? What about nextResponder?
Those three would be properties if you were starting from scratch. nextResponder would probably also be, at least for the getter.
Kendall Helmstetter Gelner
+1  A: 

Synthesized properties specify how properties are accessed. Whether or not to use synthesized properties is a design decision since properly implemented getter and setter methods will provide identical functionality.

As long as the method(s) in question can be properly implemented using the available property attributes, there is no reason why they might not be rewritten to do so.

titaniumdecoy
Deciding to declare something as a property shouldn't depend on whether it can be synthesized or not, you can still declare it as dynamic and specify your own accessor methods (or synthesize a single accessor or mutator).
Marc Charbonneau
Interesting. In that case, I suppose it makes no difference whether synthesized properties are used or not. I edited my post to reflect this.
titaniumdecoy
The @synthesize directive merely is a flag to the runtime that says "create an accessor or mutator from your template." The underlying reason for not creating properties that would back those methods is that there isn't a storage object to back them. They cause a calculation rather than a lookup.
wisequark
A: 

A property should map, intuitively if not exactly, to some storage mechanism of your class - be it an ivar declared in your @interface or something synthesized by the runtime. The act of calling a method such as canBecomeFirstResponder need not necessarily query the class for a storage mechanism which holds a trivial BOOL but rather causes some chain of events to fire off that queries the responder tree. That is to say that there is no firstResponder ivar as the value of any of those methods cannot be stored in a cache and must be determined at the time of their execution.

wisequark
See Marc's comment on my answer. You can declare a synthesized property as dynamic and specify your own accessor/mutator method(s).
titaniumdecoy
That doesn't mean anything. The point is that the dot syntax for properties implies certain things like fast lookups and ascertaining responder query answers isn't guaranteed to be *as* fast as, say, getting an intValue hence why they are not properties.
wisequark