Private Methods
-
How do I make a method private?
I have tried putting @private before the method that I want to make
private but the compiler flags a parse error. I read the
documentation and I can only find reference to private member
variables. I want to make sure that a method can only be accessed via
another method in the same class. Is this possible in Objective-C or
do I need to write this class in C++?
Many thanks.
Phil. -
On 22 Feb 2008, at 12:00, Philip Bridson wrote:
> How do I make a method private?
>
> I have tried putting @private before the method that I want to make
> private but the compiler flags a parse error. I read the
> documentation and I can only find reference to private member
> variables. I want to make sure that a method can only be accessed
> via another method in the same class. Is this possible in Objective-
> C or do I need to write this class in C++?
>
No, you can't declare methods private in an interface.
What you can do, in your .m file is declare a private interface to
your object.
E.g in MyObj.h
@interface MyObj : NSObject {
}
-(void) onePublicMethod;
@end
In MyObj.m
@interface MyObj(PrivateStuff)
-(void) aPrivateMethod;
@end;
@implementation MyObj
-(void) aPrivateMethod
{
// Do something
}
-(void) onePublicMethod
{
[self aPrivateMethod];
}
@end
As with all Obj-C stuff though, if someone finds out about your method
signature, then there is nothing to stop them calling it.
Matt -
It's not possible to do this. ObjC will allow you to send any message
to any other object. The best you can do is not publicly expose the
method and that is exactly what the Cocoa framework does. To be
honest, trying to use C++ just for this seems a waste of time; perhaps
you should explain why you want to do this? Is it to try and partition
your code up, is this something that really MUST stop, say, plugins
from accessing the code?
Mike.
On 22 Feb 2008, at 11:00, Philip Bridson wrote:
> How do I make a method private?
>
> I have tried putting @private before the method that I want to make
> private but the compiler flags a parse error. I read the
> documentation and I can only find reference to private member
> variables. I want to make sure that a method can only be accessed
> via another method in the same class. Is this possible in Objective-
> C or do I need to write this class in C++?
>
> Many thanks.
>
> Phil.
-
Le 22 févr. 08 à 12:00, Philip Bridson a écrit :
> How do I make a method private?
>
> I have tried putting @private before the method that I want to make
> private but the compiler flags a parse error. I read the
> documentation and I can only find reference to private member
> variables. I want to make sure that a method can only be accessed
> via another method in the same class. Is this possible in Objective-
> C or do I need to write this class in C++?
>
> Many thanks.
>
> Phil.
If you realy want to call this method only from your class, you can
convert it into a function (instead of using C++).
As long as this function stay in the class implementation (between
@implementation and @end) you can access private variable using the
self->_ivar syntaxt.
- (void)myPrivateMethod:(id)arg {
/* do whatever you want */
}
static void myPrivateFunction(MyClass *self, id arg) {
/* do whatever you want */
} -
Lack of private methods is a serious flaw in Obj-C IMO. There are
just as many reasons why someone would want to make a variable private
as they would want to make a method private. For example if your
writing a class that is part of a library that other developers will
be using (quite common in large projects). You may want to hide
implementation details from them, or prevent them from calling a
method that requires another to be called before/after it in order to
work properly etc (in other words, prevent them from shooting
themselves in the foot by calling methods they shouldn't be). Being
able to do this type of thing is one of the more powerful/useful
features of C++ IMO.
--Rob
On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:
> It's not possible to do this. ObjC will allow you to send any
> message to any other object. The best you can do is not publicly
> expose the method and that is exactly what the Cocoa framework does.
> To be honest, trying to use C++ just for this seems a waste of time;
> perhaps you should explain why you want to do this? Is it to try and
> partition your code up, is this something that really MUST stop,
> say, plugins from accessing the code?
>
> Mike.
>
> On 22 Feb 2008, at 11:00, Philip Bridson wrote:
>
>> How do I make a method private?
>>
>> I have tried putting @private before the method that I want to make
>> private but the compiler flags a parse error. I read the
>> documentation and I can only find reference to private member
>> variables. I want to make sure that a method can only be accessed
>> via another method in the same class. Is this possible in Objective-
>> C or do I need to write this class in C++?
>>
>> Many thanks.
>>
>> Phil.
-
This is an old Eiffel vs SmallTalk discussion. Should errors occured
at compile time or at runtime?
Anyway, I do not understand what prevent you to hide implementation
details to other developers?
As other state, if you do not declare your method in an exported
header, how do other developers will use them?
Le 22 févr. 08 à 12:48, Rob Petrovec a écrit :
> Lack of private methods is a serious flaw in Obj-C IMO. There are
> just as many reasons why someone would want to make a variable
> private as they would want to make a method private. For example if
> your writing a class that is part of a library that other developers
> will be using (quite common in large projects). You may want to
> hide implementation details from them, or prevent them from calling
> a method that requires another to be called before/after it in order
> to work properly etc (in other words, prevent them from shooting
> themselves in the foot by calling methods they shouldn't be). Being
> able to do this type of thing is one of the more powerful/useful
> features of C++ IMO.
>
> --Rob
>
>
> On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:
>
>> It's not possible to do this. ObjC will allow you to send any
>> message to any other object. The best you can do is not publicly
>> expose the method and that is exactly what the Cocoa framework
>> does. To be honest, trying to use C++ just for this seems a waste
>> of time; perhaps you should explain why you want to do this? Is it
>> to try and partition your code up, is this something that really
>> MUST stop, say, plugins from accessing the code?
>>
>> Mike.
>>
>> On 22 Feb 2008, at 11:00, Philip Bridson wrote:
>>
>>> How do I make a method private?
>>>
>>> I have tried putting @private before the method that I want to
>>> make private but the compiler flags a parse error. I read the
>>> documentation and I can only find reference to private member
>>> variables. I want to make sure that a method can only be accessed
>>> via another method in the same class. Is this possible in
>>> Objective-C or do I need to write this class in C++?
>>>
>>> Many thanks.
>>>
>>> Phil.
>
-
I agree.
Your point hit the nail on the head and is exactly the reason that I
do not want this method to be public. If it is called externally it
will cause an error. Even if I put the 'private' method into the .m
file it can still be found by using the pop up list of methods
available. Although, why some one would want to try to do something
they are not supposed to is a mystery, but that does not mean that
someone won't try.
Thank you all for your help.
Phil.
On 22 Feb 2008, at 11:48, Rob Petrovec wrote:
> Lack of private methods is a serious flaw in Obj-C IMO. There are
> just as many reasons why someone would want to make a variable
> private as they would want to make a method private. For example
> if your writing a class that is part of a library that other
> developers will be using (quite common in large projects). You may
> want to hide implementation details from them, or prevent them from
> calling a method that requires another to be called before/after it
> in order to work properly etc (in other words, prevent them from
> shooting themselves in the foot by calling methods they shouldn't
> be). Being able to do this type of thing is one of the more
> powerful/useful features of C++ IMO.
>
> --Rob
>
>
> On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:
>
>> It's not possible to do this. ObjC will allow you to send any
>> message to any other object. The best you can do is not publicly
>> expose the method and that is exactly what the Cocoa framework
>> does. To be honest, trying to use C++ just for this seems a waste
>> of time; perhaps you should explain why you want to do this? Is it
>> to try and partition your code up, is this something that really
>> MUST stop, say, plugins from accessing the code?
>>
>> Mike.
>>
>> On 22 Feb 2008, at 11:00, Philip Bridson wrote:
>>
>>> How do I make a method private?
>>>
>>> I have tried putting @private before the method that I want to
>>> make private but the compiler flags a parse error. I read the
>>> documentation and I can only find reference to private member
>>> variables. I want to make sure that a method can only be accessed
>>> via another method in the same class. Is this possible in
>>> Objective-C or do I need to write this class in C++?
>>>
>>> Many thanks.
>>>
>>> Phil.
>
-
Just to finish the discussion, but I have also just found out that
you cannot overload functions in Objective-C to accept different
arguments. I feel this is also an important feature that needs to be
addressed.
Phil.
On 22 Feb 2008, at 12:16, Philip Bridson wrote:
> I agree.
>
> Your point hit the nail on the head and is exactly the reason that
> I do not want this method to be public. If it is called externally
> it will cause an error. Even if I put the 'private' method into
> the .m file it can still be found by using the pop up list of
> methods available. Although, why some one would want to try to do
> something they are not supposed to is a mystery, but that does not
> mean that someone won't try.
>
> Thank you all for your help.
>
> Phil.
>
> On 22 Feb 2008, at 11:48, Rob Petrovec wrote:
>
>> Lack of private methods is a serious flaw in Obj-C IMO. There are
>> just as many reasons why someone would want to make a variable
>> private as they would want to make a method private. For example
>> if your writing a class that is part of a library that other
>> developers will be using (quite common in large projects). You
>> may want to hide implementation details from them, or prevent them
>> from calling a method that requires another to be called before/
>> after it in order to work properly etc (in other words, prevent
>> them from shooting themselves in the foot by calling methods they
>> shouldn't be). Being able to do this type of thing is one of the
>> more powerful/useful features of C++ IMO.
>>
>> --Rob
>>
>>
>> On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:
>>
>>> It's not possible to do this. ObjC will allow you to send any
>>> message to any other object. The best you can do is not publicly
>>> expose the method and that is exactly what the Cocoa framework
>>> does. To be honest, trying to use C++ just for this seems a waste
>>> of time; perhaps you should explain why you want to do this? Is
>>> it to try and partition your code up, is this something that
>>> really MUST stop, say, plugins from accessing the code?
>>>
>>> Mike.
>>>
>>> On 22 Feb 2008, at 11:00, Philip Bridson wrote:
>>>
>>>> How do I make a method private?
>>>>
>>>> I have tried putting @private before the method that I want to
>>>> make private but the compiler flags a parse error. I read the
>>>> documentation and I can only find reference to private member
>>>> variables. I want to make sure that a method can only be
>>>> accessed via another method in the same class. Is this possible
>>>> in Objective-C or do I need to write this class in C++?
>>>>
>>>> Many thanks.
>>>>
>>>> Phil.
>>
-
I don't agree at all. :)
Whatever you declare in the header file of your class will be the
public API that establishes the "contract" between you and the users
of your code. "If you use my class this way, it will behave correctly
and do this and that stuff for you". It's in the best interest of the
users of your code to not shoot themselves in the foot, so they're
likely to follow good practices and avoid poking around your private
stuff so that their stuff works flawlessly, and remains so even after
they perform an update of your classes to a more recent version.
What do you gain by deciding (and forcing) what a user of the code can
and cannot do with it?
--
João Pavão
On 2008/02/22, at 12:16, Philip Bridson wrote:
> I agree.
>
> Your point hit the nail on the head and is exactly the reason that I
> do not want this method to be public. If it is called externally it
> will cause an error. Even if I put the 'private' method into the .m
> file it can still be found by using the pop up list of methods
> available. Although, why some one would want to try to do something
> they are not supposed to is a mystery, but that does not mean that
> someone won't try.
>
> Thank you all for your help.
>
> Phil.
>
> On 22 Feb 2008, at 11:48, Rob Petrovec wrote:
>
>> Lack of private methods is a serious flaw in Obj-C IMO. There are
>> just as many reasons why someone would want to make a variable
>> private as they would want to make a method private. For example
>> if your writing a class that is part of a library that other
>> developers will be using (quite common in large projects). You may
>> want to hide implementation details from them, or prevent them from
>> calling a method that requires another to be called before/after it
>> in order to work properly etc (in other words, prevent them from
>> shooting themselves in the foot by calling methods they shouldn't
>> be). Being able to do this type of thing is one of the more
>> powerful/useful features of C++ IMO.
>>
>> --Rob
>>
>>
>> On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:
>>
>>> It's not possible to do this. ObjC will allow you to send any
>>> message to any other object. The best you can do is not publicly
>>> expose the method and that is exactly what the Cocoa framework
>>> does. To be honest, trying to use C++ just for this seems a waste
>>> of time; perhaps you should explain why you want to do this? Is it
>>> to try and partition your code up, is this something that really
>>> MUST stop, say, plugins from accessing the code?
>>>
>>> Mike.
>>>
>>> On 22 Feb 2008, at 11:00, Philip Bridson wrote:
>>>
>>>> How do I make a method private?
>>>>
>>>> I have tried putting @private before the method that I want to
>>>> make private but the compiler flags a parse error. I read the
>>>> documentation and I can only find reference to private member
>>>> variables. I want to make sure that a method can only be accessed
>>>> via another method in the same class. Is this possible in
>>>> Objective-C or do I need to write this class in C++?
>>>>
>>>> Many thanks.
>>>>
>>>> Phil.
>>
-
Also disagree on that one. :)
Function/method overloading based on the static types of the arguments
is just a compile-time feature that adds no value whatsoever, probably
only adds a bit of confusion for the programmer.
The ...WithX:, ...WithY: methods look fine to me! Much more
descriptive and self documenting.
--
João Pavão
PS: Maybe I got too influenced by the opinions of one of my LISP
adoring professors from college. :)
On 2008/02/22, at 12:38, Philip Bridson wrote:
> Just to finish the discussion, but I have also just found out that
> you cannot overload functions in Objective-C to accept different
> arguments. I feel this is also an important feature that needs to be
> addressed.
>
> Phil.
>
> On 22 Feb 2008, at 12:16, Philip Bridson wrote:
>
>> I agree.
>>
>> Your point hit the nail on the head and is exactly the reason that
>> I do not want this method to be public. If it is called externally
>> it will cause an error. Even if I put the 'private' method into
>> the .m file it can still be found by using the pop up list of
>> methods available. Although, why some one would want to try to do
>> something they are not supposed to is a mystery, but that does not
>> mean that someone won't try.
>>
>> Thank you all for your help.
>>
>> Phil.
>>
>> On 22 Feb 2008, at 11:48, Rob Petrovec wrote:
>>
>>> Lack of private methods is a serious flaw in Obj-C IMO. There are
>>> just as many reasons why someone would want to make a variable
>>> private as they would want to make a method private. For example
>>> if your writing a class that is part of a library that other
>>> developers will be using (quite common in large projects). You
>>> may want to hide implementation details from them, or prevent them
>>> from calling a method that requires another to be called before/
>>> after it in order to work properly etc (in other words, prevent
>>> them from shooting themselves in the foot by calling methods they
>>> shouldn't be). Being able to do this type of thing is one of the
>>> more powerful/useful features of C++ IMO.
>>>
>>> --Rob
>>>
>>>
>>> On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:
>>>
>>>> It's not possible to do this. ObjC will allow you to send any
>>>> message to any other object. The best you can do is not publicly
>>>> expose the method and that is exactly what the Cocoa framework
>>>> does. To be honest, trying to use C++ just for this seems a waste
>>>> of time; perhaps you should explain why you want to do this? Is
>>>> it to try and partition your code up, is this something that
>>>> really MUST stop, say, plugins from accessing the code?
>>>>
>>>> Mike.
>>>>
>>>> On 22 Feb 2008, at 11:00, Philip Bridson wrote:
>>>>
>>>>> How do I make a method private?
>>>>>
>>>>> I have tried putting @private before the method that I want to
>>>>> make private but the compiler flags a parse error. I read the
>>>>> documentation and I can only find reference to private member
>>>>> variables. I want to make sure that a method can only be
>>>>> accessed via another method in the same class. Is this possible
>>>>> in Objective-C or do I need to write this class in C++?
>>>>>
>>>>> Many thanks.
>>>>>
>>>>> Phil.
>>>
-
> What do you gain by deciding (and forcing) what a user of the code
> can and cannot do with it?
Is that not the whole reason that @public, @protected and @private
are used? To limit what the user has access to?
We write classes that provide a certain functionality to the user of
our class. We define what a user can and cannot do with our class. I
agree that it is in the best interest of the users not to poke around
in our private methods but accidents happen unfortunately and isn't
it our job as a developer to protect against such events? Isn't half
the code we write put there to fix errors, bugs or to prevent
possible errors? We, as developers, should not develop code that has
a known error and submit it on the basis that we trust the end user
will have the sense not to call the wrong function. Accidents happen.
Phil.
On 22 Feb 2008, at 12:41, João Pavão wrote:
> I don't agree at all. :)
>
> Whatever you declare in the header file of your class will be the
> public API that establishes the "contract" between you and the
> users of your code. "If you use my class this way, it will behave
> correctly and do this and that stuff for you". It's in the best
> interest of the users of your code to not shoot themselves in the
> foot, so they're likely to follow good practices and avoid poking
> around your private stuff so that their stuff works flawlessly, and
> remains so even after they perform an update of your classes to a
> more recent version.
>
> What do you gain by deciding (and forcing) what a user of the code
> can and cannot do with it?
> --
> João Pavão
>
>
>
> On 2008/02/22, at 12:16, Philip Bridson wrote:
>
>> I agree.
>>
>> Your point hit the nail on the head and is exactly the reason that
>> I do not want this method to be public. If it is called externally
>> it will cause an error. Even if I put the 'private' method into
>> the .m file it can still be found by using the pop up list of
>> methods available. Although, why some one would want to try to do
>> something they are not supposed to is a mystery, but that does not
>> mean that someone won't try.
>>
>> Thank you all for your help.
>>
>> Phil.
>>
>> On 22 Feb 2008, at 11:48, Rob Petrovec wrote:
>>
>>> Lack of private methods is a serious flaw in Obj-C IMO. There
>>> are just as many reasons why someone would want to make a
>>> variable private as they would want to make a method private.
>>> For example if your writing a class that is part of a library
>>> that other developers will be using (quite common in large
>>> projects). You may want to hide implementation details from
>>> them, or prevent them from calling a method that requires another
>>> to be called before/after it in order to work properly etc (in
>>> other words, prevent them from shooting themselves in the foot by
>>> calling methods they shouldn't be). Being able to do this type
>>> of thing is one of the more powerful/useful features of C++ IMO.
>>>
>>> --Rob
>>>
>>>
>>> On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:
>>>
>>>> It's not possible to do this. ObjC will allow you to send any
>>>> message to any other object. The best you can do is not publicly
>>>> expose the method and that is exactly what the Cocoa framework
>>>> does. To be honest, trying to use C++ just for this seems a
>>>> waste of time; perhaps you should explain why you want to do
>>>> this? Is it to try and partition your code up, is this something
>>>> that really MUST stop, say, plugins from accessing the code?
>>>>
>>>> Mike.
>>>>
>>>> On 22 Feb 2008, at 11:00, Philip Bridson wrote:
>>>>
>>>>> How do I make a method private?
>>>>>
>>>>> I have tried putting @private before the method that I want to
>>>>> make private but the compiler flags a parse error. I read the
>>>>> documentation and I can only find reference to private member
>>>>> variables. I want to make sure that a method can only be
>>>>> accessed via another method in the same class. Is this possible
>>>>> in Objective-C or do I need to write this class in C++?
>>>>>
>>>>> Many thanks.
>>>>>
>>>>> Phil.
>>>
>
-
Le 22 févr. 08 à 14:04, Philip Bridson a écrit :
>> What do you gain by deciding (and forcing) what a user of the code
>> can and cannot do with it?
>
> Is that not the whole reason that @public, @protected and @private
> are used? To limit what the user has access to?
>
> We write classes that provide a certain functionality to the user of
> our class. We define what a user can and cannot do with our class. I
> agree that it is in the best interest of the users not to poke
> around in our private methods but accidents happen unfortunately and
> isn't it our job as a developer to protect against such events?
> Isn't half the code we write put there to fix errors, bugs or to
> prevent possible errors? We, as developers, should not develop code
> that has a known error and submit it on the basis that we trust the
> end user will have the sense not to call the wrong function.
> Accidents happen.
>
> Phil.
>
> On 22 Feb 2008, at 12:41, João Pavão wrote:
ivar MUST be declared in the public header, so you need a way to
restrict access. This is not the case for methods. Declaring a method
in the .m file mean this is a private method and used of your class
will never see the method declaration.
Give a place where the lack of private method is a problem in the
Cocoa framework for example. -
On Feb 22, 2008, at 6:48 AM, Rob Petrovec wrote:
> Lack of private methods is a serious flaw in Obj-C IMO.
This is silly. Private is really just about as voluntary in C++ as it
is in ObjC. If a user of your class wants to ignore your decisions
about what should be private methods, they have only to write:
#define private public
#include "yourclass.h"
#undef private
void foo() {
YourClass obj;
obj.aPrivateMethod(); // no compiler errors or warnings
}
So declaring things private in C++ is just an advisory to users of
your class that certain methods and fields aren't intended to be used
by clients of the class, it's not meant as any kind of security
mechanism. In ObjC you can achieve the same thing by not declaring
methods in the interface file, so if a user of your class still finds
out about the method somehow and calls it, they'll get a compiler
warning and will know they're doing something not intended by the
class's author.
Note that this is in contrast to Java or C#, which run in managed
environments, and where private really can be used to fairly securely
block certain methods and fields from being accessed, when using the
correct security settings in the VM.
That said I do agree that it's nicer to have a formal language
construct for specifying what's private, like in C++, than the ad-hoc
mechanisms available in ObjC. I just don't agree that it's really a
serious flaw, more of a minor flaw. -
On Feb 22, 2008, at 5:23 AM, <matt.gough...> wrote:
> In MyObj.m
>
> @interface MyObj(PrivateStuff)
> -(void) aPrivateMethod;
> @end;
>
> @implementation MyObj
>
> -(void) aPrivateMethod
> {
> // Do something
> }
>
> -(void) onePublicMethod
> {
> [self aPrivateMethod];
> }
> @end
Not to be too picky, but there's an extra semicolon after @end;
@interface MyObj(PrivateStuff)
-(void) aPrivateMethod;
@end
Adhamh -
Le 22 févr. 08 à 15:57, Adhamh Findlay a écrit :
>
> On Feb 22, 2008, at 5:23 AM, <matt.gough...> wrote:
>
>> In MyObj.m
>>
>> @interface MyObj(PrivateStuff)
>> -(void) aPrivateMethod;
>> @end;
>>
>> @implementation MyObj
>>
>> -(void) aPrivateMethod
>> {
>> // Do something
>> }
>>
>> -(void) onePublicMethod
>> {
>> [self aPrivateMethod];
>> }
>> @end
>
> Not to be too picky, but there's an extra semicolon after @end;
>
> @interface MyObj(PrivateStuff)
> -(void) aPrivateMethod;
> @end
>
> Adhamh
If you want to be picky, I will also add that using a class extension
will be more appropriate, so the compiler will emit a warning if you
do not implements the private methods:
@interface MyObj ()
-(void) aPrivateMethod;
@end -
Please do log this as a bug/feature request for obj-c. (To make
@private, etc work on methods).
-corbin
On Feb 22, 2008, at 3:00 AM, Philip Bridson wrote:
> How do I make a method private?
-
On Feb 22, 2008, at 6:08 AM, Adam P Jenkins wrote:
> On Feb 22, 2008, at 6:48 AM, Rob Petrovec wrote:
>
>> Lack of private methods is a serious flaw in Obj-C IMO.
>
> This is silly. Private is really just about as voluntary in C++ as
> it is in ObjC. If a user of your class wants to ignore your
> decisions about what should be private methods, they have only to
> write:
>
> #define private public
> #include "yourclass.h"
> #undef private
>
> void foo() {
> YourClass obj;
> obj.aPrivateMethod(); // no compiler errors or warnings
> }
>
> So declaring things private in C++ is just an advisory to users of
> your class that certain methods and fields aren't intended to be
> used by clients of the class, it's not meant as any kind of security
> mechanism. In ObjC you can achieve the same thing by not declaring
> methods in the interface file, so if a user of your class still
> finds out about the method somehow and calls it, they'll get a
> compiler warning and will know they're doing something not intended
> by the class's author.
>
> Note that this is in contrast to Java or C#, which run in managed
> environments, and where private really can be used to fairly
> securely block certain methods and fields from being accessed, when
> using the correct security settings in the VM.
>
> That said I do agree that it's nicer to have a formal language
> construct for specifying what's private, like in C++, than the ad-
> hoc mechanisms available in ObjC. I just don't agree that it's
> really a serious flaw, more of a minor
> flaw._______________________________________________
If a method is private, why would you ever want to place it in a
public header? I could see a justification for @proected applying to
methods, but it seems much better to just not have the private methods
in the interface at all. Putting a private method in the interface
says "This exists, and you can't use it." If I can't use it, why are
you telling me it is there?
I believe that in c++ the MyClass.h file is the *only* interface to
your class. In objective-c, the MyClass.h file is simply the public
interface to your class. You're free to have more than one @interface
and you are encouraged to use them to declare things that shouldn't be
part of your outward facing public interface.
Things would be best if we didn't even have to put our private
instance variables in the header -
Jon Hess
>
>
> Cocoa-dev mailing list (<Cocoa-dev...>)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<jhess...>
>
> This email sent to <jhess...>
-
On Feb 23, 2008, at 5:15 PM, Jonathan Hess wrote:
>
> On Feb 22, 2008, at 6:08 AM, Adam P Jenkins wrote:
>
>> On Feb 22, 2008, at 6:48 AM, Rob Petrovec wrote:
>>
>>> Lack of private methods is a serious flaw in Obj-C IMO.
>>
>> This is silly. Private is really just about as voluntary in C++ as
>> it is in ObjC. If a user of your class wants to ignore your
>> decisions about what should be private methods, they have only to
>> write:
>>
>> #define private public
>> #include "yourclass.h"
>> #undef private
>>
>> void foo() {
>> YourClass obj;
>> obj.aPrivateMethod(); // no compiler errors or warnings
>> }
>>
>> So declaring things private in C++ is just an advisory to users of
>> your class that certain methods and fields aren't intended to be
>> used by clients of the class, it's not meant as any kind of
>> security mechanism. In ObjC you can achieve the same thing by not
>> declaring methods in the interface file, so if a user of your class
>> still finds out about the method somehow and calls it, they'll get
>> a compiler warning and will know they're doing something not
>> intended by the class's author.
>>
>> Note that this is in contrast to Java or C#, which run in managed
>> environments, and where private really can be used to fairly
>> securely block certain methods and fields from being accessed, when
>> using the correct security settings in the VM.
>>
>> That said I do agree that it's nicer to have a formal language
>> construct for specifying what's private, like in C++, than the ad-
>> hoc mechanisms available in ObjC. I just don't agree that it's
>> really a serious flaw, more of a minor
>> flaw._______________________________________________
>
> If a method is private, why would you ever want to place it in a
> public header? I could see a justification for @proected applying to
> methods, but it seems much better to just not have the private
> methods in the interface at all. Putting a private method in the
> interface says "This exists, and you can't use it." If I can't use
> it, why are you telling me it is there?
>
> I believe that in c++ the MyClass.h file is the *only* interface to
> your class. In objective-c, the MyClass.h file is simply the public
> interface to your class. You're free to have more than one
> @interface and you are encouraged to use them to declare things that
> shouldn't be part of your outward facing public interface.
>
> Things would be best if we didn't even have to put our private
> instance variables in the header -
> Jon Hess
I agree that this is a way in which ObjC is actually better about
separating public from private than C++, that you don't need to add
private methods to the public header file at all, though the same
problem still exists for instance variables, at least with the 32 bit
runtime. You can get the same effect in C++ though by using the Pimpl
idiom: http://c2.com/cgi/wiki?PimplIdiom .
Adam
