0

I'm still new to Objective-C and I recently learned how to make properties, so far so good, but one thing that bothers me is that the setter and getter methods are still publicly available even after the property is made.
let's say I have the following code:

// myClass.h
@interface myClass : NSObject {
int _startPos;
}
@property (assign, readwrite, setter = setStartPos:, getter = getStartPos) int startPos;
-(void) setStartPos: (int) pos;
-(int) getStartPos;
@end

the implementation file should be rather self-explanatory, I'm not trying to do anything specific.
Now, I read somewhere, and tried it in practice that if you make a category in the implementation file, and add some methods to that, it's possible to make those methods invisible (aka private) to things outside of the myClass.m file.

"Alright" I think, and decide to try it out:

//myClass.m
#import <Foundation/Foundation.h>
#import "myClass.h"

@interface myClass (hidden)
-(void) setHiddenStartPos: (int) hPos;
-(int) getHiddenStartPos;
@end

@implementation myClass (hidden)
-(void) setHiddenStartPos: (int) hPos {
_startPos = hPos;
}

-(int) getHiddenStartPos {
return _startPos;
}
@end

@implementation myClass
-(void) setStartPos: (int) Pos {
[self setHiddenStartPos: Pos];
}

-(int) getStartPos {
return [self getHiddenStartPos]; //this is to see if I can get the value from the hidden methods through the non-hidden ones
}
@end

that's all fine, and testing it in main() I can see that the methods with "hidden" in their name are in fact inaccessible, and therefore act as if they are private.

Then I tried to add this to the header file:

@property (assign, readwrite, setter = setHiddenStartPos:, getter = getHiddenStartPos) int

to see if I could access the hidden methods through the property
but when I did that, the hidden methods became accessible in main() and the whole plan with making the methods only accessible through the property went down the drain

So I ask you, is there a way to make methods inaccessible to anything BUT the property and/or the object itself?

Edit: I realize that getters don't usually have get in the name, so please stop commenting on it?

also to emphasise what I meant: I wanted to make properties like in c#, where the content of the setters and getters are private to the property itself

public int exampleProperty
{
    set{...}
    get{...}
}

it doesn't use methods as getters and setters, and therefore the code in the setters and getters are accessible to only the property, JUST like the code within a method is local to the method itself

Electric Coffee
  • 11,733
  • 9
  • 70
  • 131

3 Answers3

4

Add a class continuation in your .m file. i.e.:

@interface myClass ()
@property (assign, readwrite, setter = setHiddenStartPos:, getter = getHiddenStartPos) int hiddenStartPos;
@end

@implimentation myClass
@synthesize hiddenStartPos = _hiddenStartPos;
...
@end

Have a look at: What is an Objective-C "class continuation"?

PS: Your getters should just be hiddenStartPos rather than getHiddenStartPos...

Community
  • 1
  • 1
hypercrypt
  • 15,389
  • 6
  • 48
  • 59
  • doing what you described just gives me an error that says "property declared in category 'hidden' cannot be implemented in class implementation" – Electric Coffee Aug 12 '12 at 14:06
  • 3
    Getter methods **should not** be prefixed with `get`. (Just adding emphasis). – bbum Aug 12 '12 at 14:23
  • 1
    Get rid of your category, just have the class continuation – hypercrypt Aug 12 '12 at 16:20
  • specifically, you must declare it `@interface myClass ()`, rather than `@interface myClass (hidden)` -- the continuation is declared as a category with **no name** `()`, and its methods and properties may be placed in `@implementation myClass` – justin Aug 12 '12 at 20:30
2

It seems to me that the your confusion comes from misunderstanding exactly what an @property declaration is. It is essentially a declaration that setter and getter methods exist.

So, this

@property int hiddenStartPos;

is the same as this

- (int)hiddenStartPos;
- (void)setHiddenStartPos;

So, the implementation of these two methods is the implementation of the property. By decaring the property in the .h file, you're advertising to anyone who imports the .h that the class in question implements these two methods (the getter and the setter, respectively).

I also want to reemphasize that getter methods should not be prefixed with "get" in Objective-C.

Andrew Madsen
  • 21,309
  • 5
  • 56
  • 97
  • all standard getters in java are prefixed with get. but I wanted to make properties like in c#, where the content of the setters and getters are private to the property itself `public int exampleProperty` `{` `set{...}` `get{...}` `}` it doesn't use methods as getters and setters, and therefore the code in the setters and getters are accessible to only itself – Electric Coffee Aug 12 '12 at 15:13
  • The names of accessors have specific meanings in ObjC. You must not put `get` on the front of your getters. It's not just style; it's how Key-Value Coding works, which is the basis for much of Cocoa. `get...` means that you're passing a variable and expect it to be updated by reference. – Rob Napier Aug 12 '12 at 19:56
1

You're over-thinking what "private" means. In ObjC, "private" just means "not visible." It doesn't mean "not callable." The way you make a method private is to not put it in your .h file, which declares your public interface.

There is no way to control who passes a message. This is a key fact of ObjC and cannot (and should not) be changed. ObjC is a dynamic language. At runtime, I am free to generate selectors and call performSelector: on any object I want. Anything that stopped that would either (a) introduce significant performance penalties, or (b) break many very useful and common techniques in ObjC (probably both). ObjC is not Java or C#. It's not even C or C++. It's Smalltalk on top of C. It's a highly dynamic language and that has a lot of strengths. Unlearning other languages is the first step towards becoming a good Cocoa developer.

It would be nice to have a compiler-checked @private for methods (of which properties are just a special case), and it would especially be awesome to have a compiler-checked @protected for methods (these exist for ivars). These would make it slightly simpler to avoid some kinds of mistakes. But that's the only way you should be thinking about this. The goal is not to protect one part of the code from another part of the code. The other code is not the enemy. It's all written by people who want the program to work. The goal is to avoid mistakes. Correct naming, consistency, and the absolute elimination of warnings is how you achieve that in ObjC.

So yes, I'd love to be able to put @protected in front of my @property declarations occasionally. Today you can't, and there is no real equivalent (I sometimes use a +Protected category in a separate header, but it's generally more trouble than its worth). But that said, having it wouldn't change very much, and I only find a case where I would even use this a few times a year. I can't think of single case where @private for a method would have been really useful, though.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610