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
previous month february 2008 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29    
Go to today