iPhone Developer Tips Visitor Stats:
122,631 Pageviews and 90,229 visitors in the past 30 days.
|
While scanning a few code examples inside the iPhone SDK, I bumped into something interesting. I wrote a short example to mimic what I found…take a look at the following interface declaration:
1
2
3
4
5
6
7
8
9
| @interface SomeClass : NSObject
{
NSString *str;
NSDate *date;
}
@property (nonatomic, retain) NSString *str;
@property (nonatomic, retain) NSDate *date;
@property (readonly) NSString *testSomething; |
The only aspect that should standout is the property declaration for testSomething . Notice there is no instance instance variable tied to this declaration. This is different if for no reason other than the typical use for properties is as a shorthand for declaring accessor methods for instance variables.
So what happens if we now add an instance method, such as shown below, inside the implementation file for SomeClass (and don’t include either a @synthesize or @dynamic declaration)?
1
2
3
4
| - (NSString *) testSomething
{
return @"Foo";
} |
Well, for one thing, we can now access the testSomething method using dot syntax.
1
2
3
| SomeClass *ptr = [[SomeClass alloc] initWithStrAndDate:@"Fubar"];
...
NSLog(@"test: %@", ptr.testSomething); |
This is intriguing. I couldn’t find any specific references to using properties in this manner. Is this simply a side-effect of how properties are implemented?
If you can shed any light on this, including whether this is a common/good practice, please post a comment.
Comments
4 Responses to “Alternative Use of Properties?”
Leave Comment
The redundancy in property declarations drives me nuts (as does some of the other unnecessary verbosity in Obj-C and Apple’s APIs).
I spotted this the other day in Apple’s Objective C Guide, under “Using properties”; so I guess at some time in the future we won’t have to put up with it:
There are differences in the behavior that depend on the runtime (see also “Runtime Differences”):
* For the legacy runtimes, instance variables must already be declared in the @interface block. If an instance variable of the same name and compatible type as the property exists, it is used—otherwise, you get a compiler error.
* For the modern runtimes, instance variables are synthesized as needed. If an instance variable of the same name already exists, it is used
Hey John, I remember from reading about properties the other day that the default value for a property directives is @dynamic. So, if you declare a property in your interface, but do not specify @synthesize in your implementation it will default to dynamic and expect you to implement a getter/setter corresponding to the @property you’ve defined in the implementation or at runtime.
I think it is because properties do not need to be directly tied to individual ivars.
How about this as an example
@interface SomeClass : NSObject
{
NSString *firstName
NSString *lastName
}
@property (copy, readwrite) NSString *firstName;
@property (copy, readwrite) NSString *lastName;
@property (readonly) NSString *fullName;
@end
Now, in the implementation, you explicitly define the getter which operates on the other properties.
- (NSString *)fullName
{
NSString *retString;
retString = [NSString stringWithFormat:(@"%@ %@", firstName, lastName)];
}
You could have used self.firstName and self.lastName above.
It’s entirely standard, use it. You can also override the property setter in the same way
-(void) setSomeProperty:(id) someValue{
[someValue retain];
[someProperty release];
someProperty = someValue;
}
Where you have a someProperty property.. of course you can put in whatever you want.