-2

Let say I have:

@interface test : NSObject {
    BOOL bVal;
}

People keep saying properties are a better way of accessing a ivar, but are they doing it just for the heck of it?

Why would I need a @property for this ivar in this case?

I'm just wondering if people know why they are doing what they are told to, or if I'm missing something.

mskw
  • 10,063
  • 9
  • 42
  • 64
  • Not true, I'm being very specific here with a simple Bool. – mskw Apr 04 '13 at 20:17
  • 1
    POD types for properties are addressed in more than a few of the many instances of this question. More importantly, what difference do you think the `BOOL` makes? – jscs Apr 04 '13 at 20:19
  • Assuming this question is going to be closed soon, there's probably no time to leave the question open so if you'll forgive me I'll jump straight in and say: that you're using "a simple Bool" makes no difference whatsoever. The key issue is encapsulation, which relates to data hiding and sovereignty, none of which are in any way contingent on the type of thing being stored or the steps necessary to store it. – Tommy Apr 04 '13 at 20:24
  • The merits of properties come and go with each version of iOS & the development system. A list of reasons that was valid a year ago would likely no longer be valid. – Hot Licks Apr 04 '13 at 20:34
  • The reason I think this should not be closed is because I'm asking a really specific question, and why not allow people to save time by go directly to what they want instead of reading an and sifting through an answer that apply broadly? – mskw Apr 04 '13 at 20:50
  • What _is_ your "specific" question, then? "Why should I use a property for a `BOOL`?" The answer is the same as for any other type, and we really do not need one question per datatype. – jscs Apr 04 '13 at 21:27
  • For other types such as objects, it sort of make sense because you can assign very specific properties such as retain/copy, but for BOOL, if you set ASSIGN, it seems completely useless, and a waste of time. – mskw Apr 04 '13 at 21:41
  • Why did you accept a completely general answer if you're so set on the idea of `BOOL` being different? – jscs Apr 05 '13 at 20:50
  • 1
    See also: [Use of properties in ObjC 2 0 for primitive types](http://stackoverflow.com/q/424962) – jscs Apr 10 '13 at 00:15

1 Answers1

1

Properties get you some nice things, like synthesized getters and setters which are sure to be written in the best way for the property's retain/strong, assign/weak, atomic or non-atomic attributes. If you don't need code outside your class accessing the ivar at all then you should probably declare the ivar in the implementation itself and keep it completely hidden from the outside, like:

@implementation test {
    BOOL bVal;
}

The answer to your other question is that it depends on the person, of course. Yes, there are plenty of people on this site parroting advice and code snippets without really understanding them. There are also plenty of people on here who really know what they're talking about.

Aaron Golden
  • 7,092
  • 1
  • 25
  • 31
  • Ok this makes sense, I'd use it only to allow access to this private ivar. Correct? – mskw Apr 04 '13 at 20:51
  • 1
    With the latest LLVM you don't even need to declare the ivar if you've got a property. If you declare a property like `@property (nonatomic, weak) BOOL bVal` the compiler will synthesize the ivar `_bVal` for you, but you have the right idea. If outside objects need to access the variable, using a property and taking advantage of the synthesized methods is usually a good idea. For private ivars in ARC code properties don't get you as much. In non-ARC code taking advantage of the synthesized getters and setters, even for private variables, can help you avoid common memory management bugs. – Aaron Golden Apr 04 '13 at 21:32
  • That's the problem, why would I want to type all of that when I can easily just type BOOL bVal? Why? I'd do it if only I assign a Atomic property. And howcome you can assign weak to the bool? – mskw Apr 04 '13 at 21:43