views:

1311

answers:

5

I have a readonly BOOL property. What is dominant naming pattern here?

Background: for plain old method declarations, the accepted pattern

- (BOOL)isEditable;
- (void)setEditable:(BOOL)flag;

In a @property world, that would typically be expressed as

@property(getter=isEditable) BOOL editable;

However, there are examples to the contrary. Such as in CalStore/CalCalendar.h

@property(readonly) BOOL isEditable;

(Is CalCalendar wrong here, or is that the also an acceptable naming pattern for read-only BOOL properties?)

I've got a controller which manages a view, which may or may not be resizable. The property is read only.

@property(readonly) BOOL viewIsResizable;
@property(readonly) BOOL isViewResizable;
@property(readonly, getter=isViewResizable) BOOL viewResizable;

Which pattern is most natural or Cocoa-like?

+2  A: 

You'd want to use the one that works with KVO, KVC and bindings etc.

I remember reading that in the Docs that KVO et al. will look for is set as well as get and many others like countOf

http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/Compliant.html#//apple_ref/doc/uid/20002172

Explains it much better than I could ever do.

rjstelling
A: 

The convention is definitely to do is... for BOOL getters. The reason you see the property set like that in CalStore is most likely because it's read-only and written that way for basic readability of the header file, since:

@property(readonly) isEditable;

is generally easier to read than:

@property(readonly, getter=isEditable) editable;

For the first type of property, in your implementation you could do either of:

@synthesize isEditable = editable;

or simply define the accessor:

- (BOOL)isEditable(void) { return editable; }

This leaves the interface file (the header) more easily readable by a potential user.

Jason Coco
In cases 2 and 3, the getter is going to be named isViewResizable. It is just a matter of what the property is named.[controller isViewResizable];butcontroller.isViewResizable or controller.viewResizableThe latter reads funny, but is consistent with[button isEditable] -> button.editable(which itself is inconsistent with CalCalendar.)
+1  A: 

I don't think it really matters, since KVO will look at both is<Key> and <Key>.

Looking at the iPhone classes, the most common pattern I've seen is:

@property(nonatomic, getter=isHidden) BOOL hidden;

This let's you access the property in these ways:

obj.hidden = YES; // (1)
BOOL hidden = obj.hidden; // (2)
BOOL hidden = [obj isHidden]; // (3)

But not:

BOOL hidden = obj.isHidden; // (4)

CalStore does not follow that convention. You would be have to use line 4 instead of line 2.

Martin Gordon
The interesting difference here (whether it is significant is another matter) is that in CalStore the property is read-only.obj.hidden = YES reads naturally, whereas obj.isHidden = YES is less so.But in the read-only case, you are never assigning the state, only querying it.
+1  A: 

The CalStore example seems to be violating the convention. I'd stick to where the property name, as opposed to the method name, doesn't have an "is" in it.

Sii
+4  A: 

quoted from ADC

If the attribute is expressed as an adjective, the format is:

- (void)setAdjective:(BOOL)flag;
- (BOOL)isAdjective;

For example:

- (void)setEditable:(BOOL)flag;
- (BOOL)isEditable;

If the attribute is expressed as a verb, the format is:

- (void)setVerbObject:(BOOL)flag; 
- (BOOL)verbObject;

For example:

- (void)setShowsAlpha:(BOOL)flag;
- (BOOL)showsAlpha;

The verb should be in the simple present tense.

|K<

kent
What kent said; your property should be named "resizable" or "viewResizable" and should declare getter=isViewResizable.
Chris Hanson