Underscore in method names

  • > You should not use methods beginning with _, Apple reserves them and
    > you might accidentally override a superclass method without meaning to.

    Yes, I know--it's my least favorite wart in practical Objective-C
    usage.  The alternatives for naming methods (in this case, private
    methods internal to a class's implementation, not to be used externally)
    seem to be:

    1) Underscore before the method name (_myMethod).  Obviously this runs
    the risk of colliding with a method that already exists, when I am
    subclassing someone else's object.  I can check against this in the
    current development environment (by running class-dump on the superclass
    and all of its superclasses), but there's still the possibility that it
    will break in the future.

    2) Just use plain names (myMethod).  This is a little safer--I still
    have to check all the public methods on all superclasses but I can just
    do that through the header files. However, I still have to do the
    class-dump to be perfectly safe, because there are some private methods
    which Apple doesn't prefix with an underscore (at least, there
    historically have been).  And it still could break in the future.  (And
    this makes it impossible to distinguish between private and public
    methods, which is a really useful thing to be able to do at a glance.)

    3) Prefix all methods with a hopefully-unique identifier (BLAH_myMethod
    or something). Very safe, very ugly.

    I have only ever seen 1 and 2 in practice.  Do people actually use
    method 3? Do you eventually get used to it?  I've been doing 1 and 2 for
    years and have never actually been bitten by a problem (yeah, yeah, I
    know that means nothing).

    By the way, I know this idea that Apple reserves method names starting
    with _ is part of the folklore, but is it actually documented anywhere?
    I can't find it in the current version of "Object-Oriented Programming
    and the Objective-C Language".    (Back in some old NeXT docs?)

    Maybe I should just switch to Java :)

    --
    Kurt Revis
    <krevis...>
  • > You should not use methods beginning with _, Apple reserves them
    > and you might accidentally override a superclass method without
    > meaning to.

    You can code your private methods as static functions. That way
    they're really private and calling them is faster.

    For what it is worth, I routinely prefix methods with _ but then I
    rarely subclass anything other than NSObject. If I subclass
    anything else from Apple (or someone else) than NSObject I get a
    lot more cautious...

    Nat!
    P.S. Mulle has reserved the "_" as a postfix to instance variables
    and methods, so there :) :)
    ------------------------------------------------------
    Some people drink deep from the fountains of life, and
    some just gargle. -- DLR
  • On Tuesday, February 26, 2002, at 02:33 PM, Kurt Revis wrote:
    > By the way, I know this idea that Apple reserves method names starting
    > with _ is part of the folklore, but is it actually documented anywhere?
    > I can't find it in the current version of "Object-Oriented Programming
    > and the Objective-C Language".    (Back in some old NeXT docs?)

    This is still very much the case!    I'll see what we can do about
    refreshing this piece of info in the docs.
    Ali
  • Kurt Revis wrote:

    >> You should not use methods beginning with _, Apple reserves them and
    >> you might accidentally override a superclass method without meaning to.
    >
    > Yes, I know--it's my least favorite wart in practical Objective-C
    > usage.  The alternatives for naming methods (in this case, private
    > methods internal to a class's implementation, not to be used externally)
    > seem to be:
    >
    > 1) Underscore before the method name (_myMethod).  Obviously this runs
    > the risk of colliding with a method that already exists, when I am
    > subclassing someone else's object.  I can check against this in the
    > current development environment (by running class-dump on the superclass
    > and all of its superclasses), but there's still the possibility that it
    > will break in the future.
    >
    > 2) Just use plain names (myMethod).  This is a little safer--I still
    > have to check all the public methods on all superclasses but I can just
    > do that through the header files. However, I still have to do the
    > class-dump to be perfectly safe, because there are some private methods
    > which Apple doesn't prefix with an underscore (at least, there
    > historically have been).  And it still could break in the future.  (And
    > this makes it impossible to distinguish between private and public
    > methods, which is a really useful thing to be able to do at a glance.)
    >
    > 3) Prefix all methods with a hopefully-unique identifier (BLAH_myMethod
    > or something). Very safe, very ugly.

    I have carried over the PowerPlant conventions myself:

    so it would be mMethodName, inParameter, outParameter, ioParameter,
    gGlobalVariable, eEnumeration, kConstant etc. although I use localVariable
    rather than theLocalVariable.
  • On Tuesday, February 26, 2002, at 02:33 PM, Kurt Revis wrote:

    > Yes, I know--it's my least favorite wart in practical Objective-C
    > usage.  The alternatives for naming methods (in this case, private
    > methods internal to a class's implementation, not to be used
    > externally) seem to be:
    >
    > 1) Underscore before the method name (_myMethod).  Obviously this runs
    > the risk of colliding with a method that already exists, when I am
    > subclassing someone else's object.  I can check against this in the
    > current development environment (by running class-dump on the
    > superclass and all of its superclasses), but there's still the
    > possibility that it will break in the future.
    >
    > 2) Just use plain names (myMethod).  This is a little safer--I still
    > have to check all the public methods on all superclasses but I can just
    > do that through the header files. However, I still have to do the
    > class-dump to be perfectly safe, because there are some private methods
    > which Apple doesn't prefix with an underscore (at least, there
    > historically have been).  And it still could break in the future.  (And
    > this makes it impossible to distinguish between private and public
    > methods, which is a really useful thing to be able to do at a glance.)
    >
    > 3) Prefix all methods with a hopefully-unique identifier (BLAH_myMethod
    > or something). Very safe, very ugly.

    4) Put an underscore at the *end* of the method name: myMethod_ .  We do
    this for data members in C++ classes at work, and it only seems natural
    to do the same for private methods.

        -g
  •   Apple either needs to add ObjC namespace support or needs to start
    using 'com_apple_' as a prefix for private methods.  I mean, if you are
    going to foist this off on all the Cocoa developers then you should be
    eating your own dog food, right?

      :)

    -tim

    On Tuesday, February 26, 2002, at 03:07  PM, Ali Ozer wrote:

    > On Tuesday, February 26, 2002, at 02:33 PM, Kurt Revis wrote:
    >> By the way, I know this idea that Apple reserves method names starting
    >> with _ is part of the folklore, but is it actually documented
    >> anywhere? I can't find it in the current version of "Object-Oriented
    >> Programming and the Objective-C Language".    (Back in some old NeXT
    >> docs?)
    >
    > This is still very much the case!    I'll see what we can do about
    > refreshing this piece of info in the docs.
    > Ali
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • Hmm. So you're advocating namespaces for methods? How would that work?

    -Kenny

    On Wednesday, February 27, 2002, at 12:04 PM, Timothy J. Wood wrote:

    > Apple either needs to add ObjC namespace support or needs to start
    > using 'com_apple_' as a prefix for private methods.  I mean, if you are
    > going to foist this off on all the Cocoa developers then you should be
    > eating your own dog food, right?
  •   (this is long and rambling -- the short answer is that @private could
    be allowed for methods and should indicate that the compiler should
    avoid runtime method lookup and just bind to the appropriate the method
    implementation directly).

      Yeah, sort of I guess :)

      This would be a big change, obviously.  I don't think I'd want
    namespaces on methods, but on classes.  So, we might have the following
    in NSView:

    @namespace com_apple_AppKit

    @interface NSView (PrivateMethods)
    - (void) _doSomething;
    @end

    @implementation NSView
    - (void) someMethod;
    {
        [self _doSomething];
    }
    @end

    @implementation NSView (PrivateMethod)
    ...
    @end

    @end // namespace com_apple_AppKit

      In this case you could sort of apply a namespace to the methods in the
    private category and do something where the method lookup would munge
    the selector name in some way under some condition (vague enough for
    you?).  For example, selectors might be modified to include the
    namespace in which they were declared.  This would be really problematic
    for subclassing across namespace boundaries so it probably wouldn't work.

      A better approach would be to namespace classes, leave selectors the
    way they are and then to make categories more powerful and more robust.
    The main problem with categories is that you can't add multiple
    categories to the same class with the same method.  So, if you want to
    modify the behavior of a class then:

      - Only one category can do this since ordering of categories is not
    well defined.
      - If the original definition is in a category, you're screwed since
    you can't access the old implementation.

      This situation could be made better by having some or all of the
    following:

    - Allow @private to apply to methods and people would have to list their
    private methods in the @interface for their private category.  The
    compiler would then directly bind to the method implementation rather
    than doing the method lookup at runtime.  The compiler could do this
    automatically when compiling a method -- if it is in class Foo calling
    method -bar and -bar is declared to be @private in Foo, then bind
    directly.  (You could also allow syntax for managing this directly --
    "[myObject(SomeCategory) someMethod];" might bind to a method imp
    directly).  This would introduce the problem of not being able to
    override a broken private method temporarily until the system software
    gets fixed.  Yes this is a bad thing to do, but it is worse in many
    cases to not be able to do this (you just have to be careful to only do
    this when you can accurately detect when the bug is fixed or guarantee
    that you'll not introduce worse problems with the system is fixed).

      You might also want to NOT list the method in the ObjC runtime in this
    case.

    - Warning/error if two categories on exist on the same class defining
    the same method names (and everyone would have to move private methods
    in to a category to get this protection to work).  This would be a
    runtime check and would thus be more robust in the face of evolving
    system software.

    - Add some sort of 'stackable' categories to ObjC.  This would be the
    most powerful but the most ill-defined and bizarre.  TOM has some stuff
    for having multiple extensions to the same class but it's been a while
    since I looked at it.  My thinking was that you'd be able to configure
    categories on the same class into a well ordered list either via a
    configuration file provided to the linker or by syntax in the compiler
    (i.e., this category comes after this other category) and logic in the
    compiler/linker to detect circular categories.  Once you have a category
    stack you could provide syntax to call the 'previous' category method.
    I'm not sure how this would tie into the runtime -- it would probably be
    ugly or involve removing more runtime method lookups (possibly bad as
    noted above, but good for performance).

      So, again, the easiest fix is that @private should work for methods
    and should cause the compiler to avoid method lookup entirely (note the
    implications for 'super' where two classes share the work of
    implementing private functionality -- super would need to be able to
    bind to the superclass implementation directly).

    -tim

    On Wednesday, February 27, 2002, at 12:22  PM, Kenny Leung wrote:

    > Hmm. So you're advocating namespaces for methods? How would that work?
    >
    > -Kenny
    >
    >
    > On Wednesday, February 27, 2002, at 12:04 PM, Timothy J. Wood wrote:
    >
    >> Apple either needs to add ObjC namespace support or needs to start
    >> using 'com_apple_' as a prefix for private methods.  I mean, if you
    >> are going to foist this off on all the Cocoa developers then you
    >> should be eating your own dog food, right?
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • Hi Tim.

    This sounds complicated. It seems to me the big problem is really the
    implicitness of methods overriding other methods. What if we just had to
    be explicit about the methods that we override? When code is loaded, the
    runtime could check that  you actually weren't overriding a method you
    thought you were (or vice versa) and barf.

    @interface NSView (PrivateMethods)
    - (void) _doSomething;
    @end

    If you had this, the runtime would barf:

    @interface MyView : NSView
    - (void) _doSomething;
    @end

    If you had this, everything would be fine.

    @interface MyView : NSView
    - (void) _doSomething overrides NSView(PrivateMethods);
    @end

    If you wanted to do method replacement, do this:

    @interface NSView (MyHacks)
    - (void) _doSomething replaces NSView(PrivateMethods);
    @end

    -Kenny

    On Wednesday, February 27, 2002, at 01:38 PM, Timothy J. Wood wrote:

    >
    >
    > (this is long and rambling -- the short answer is that @private could
    > be allowed for methods and should indicate that the compiler should
    > avoid runtime method lookup and just bind to the appropriate the method
    > implementation directly).
    >
    >
    > Yeah, sort of I guess :)
    >
    > This would be a big change, obviously.  I don't think I'd want
    > namespaces on methods, but on classes.  So, we might have the following
    > in NSView:
    >
    > @namespace com_apple_AppKit
    >
    > @interface NSView (PrivateMethods)
    > - (void) _doSomething;
    > @end
    >
    > @implementation NSView
    > - (void) someMethod;
    > {
    > [self _doSomething];
    > }
    > @end
    >
    > @implementation NSView (PrivateMethod)
    > ...
    > @end
    >
    > @end // namespace com_apple_AppKit
    >
    >
    > In this case you could sort of apply a namespace to the methods in
    > the private category and do something where the method lookup would
    > munge the selector name in some way under some condition (vague enough
    > for you?).  For example, selectors might be modified to include the
    > namespace in which they were declared.  This would be really
    > problematic for subclassing across namespace boundaries so it probably
    > wouldn't work.
    >
    > A better approach would be to namespace classes, leave selectors the
    > way they are and then to make categories more powerful and more
    > robust.  The main problem with categories is that you can't add
    > multiple categories to the same class with the same method.  So, if you
    > want to modify the behavior of a class then:
    >
    > - Only one category can do this since ordering of categories is not
    > well defined.
    > - If the original definition is in a category, you're screwed since
    > you can't access the old implementation.
    >
    > This situation could be made better by having some or all of the
    > following:
    >
    > - Allow @private to apply to methods and people would have to list
    > their private methods in the @interface for their private category.
    > The compiler would then directly bind to the method implementation
    > rather than doing the method lookup at runtime.  The compiler could do
    > this automatically when compiling a method -- if it is in class Foo
    > calling method -bar and -bar is declared to be @private in Foo, then
    > bind directly.  (You could also allow syntax for managing this
    > directly -- "[myObject(SomeCategory) someMethod];" might bind to a
    > method imp directly).  This would introduce the problem of not being
    > able to override a broken private method temporarily until the system
    > software gets fixed.  Yes this is a bad thing to do, but it is worse in
    > many cases to not be able to do this (you just have to be careful to
    > only do this when you can accurately detect when the bug is fixed or
    > guarantee that you'll not introduce worse problems with the system is
    > fixed).
    >
    > You might also want to NOT list the method in the ObjC runtime in
    > this case.
    >
    > - Warning/error if two categories on exist on the same class defining
    > the same method names (and everyone would have to move private methods
    > in to a category to get this protection to work).  This would be a
    > runtime check and would thus be more robust in the face of evolving
    > system software.
    >
    > - Add some sort of 'stackable' categories to ObjC.  This would be the
    > most powerful but the most ill-defined and bizarre.  TOM has some stuff
    > for having multiple extensions to the same class but it's been a while
    > since I looked at it.  My thinking was that you'd be able to configure
    > categories on the same class into a well ordered list either via a
    > configuration file provided to the linker or by syntax in the compiler
    > (i.e., this category comes after this other category) and logic in the
    > compiler/linker to detect circular categories.  Once you have a
    > category stack you could provide syntax to call the 'previous' category
    > method.  I'm not sure how this would tie into the runtime -- it would
    > probably be ugly or involve removing more runtime method lookups
    > (possibly bad as noted above, but good for performance).
    >
    >
    > So, again, the easiest fix is that @private should work for methods
    > and should cause the compiler to avoid method lookup entirely (note the
    > implications for 'super' where two classes share the work of
    > implementing private functionality -- super would need to be able to
    > bind to the superclass implementation directly).
    >
    >
    > -tim
    >
    >
    >
    > On Wednesday, February 27, 2002, at 12:22  PM, Kenny Leung wrote:
    >
    >> Hmm. So you're advocating namespaces for methods? How would that work?
    >>
    >> -Kenny
    >>
    >>
    >> On Wednesday, February 27, 2002, at 12:04 PM, Timothy J. Wood wrote:
    >>
    >>> Apple either needs to add ObjC namespace support or needs to start
    >>> using 'com_apple_' as a prefix for private methods.  I mean, if you
    >>> are going to foist this off on all the Cocoa developers then you
    >>> should be eating your own dog food, right?
    >>
    >> _______________________________________________
    >> MacOSX-dev mailing list
    >> <MacOSX-dev...>
    >> http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • It sounds like your suggestion is that @private applied to Objective-C
    methods should work like the "final" key word in Java.

    Why not just implement such "private" methods as functions that take a
    "self" argument and are implemented inside an @implementation/@end block ?

    @implementation SomeClass

    static int _SomePrivateFunction(id self, int someArg1, NSString *someArg2)
    {
      NSString    *tempString = [[NSString alloc] initWithFormat:@%@:%d %@,
    [[self class] description],
          someArg1, someArg2];
      int                result = [tempString  length];

      [tempString release];

      return result;
    }

    - (void)somePublicMethod:(NSString *)fubar
    {
      static int        counter = 0;

      SomePrivateFunction(self, counter ++, fubar);
    }

    @end

    Doesn't that give you exactly what you want with the @private keyword
    applied to methods ?
  •   This is pretty much how the compiler would implement it, yes.  But,
    the advantage to doing it with @private would be that the private method
    could access private and protected ivars in the object nicely.

    -tim

    On Wednesday, February 27, 2002, at 02:27  PM, Erik M. Buck wrote:

    > It sounds like your suggestion is that @private applied to Objective-C
    > methods should work like the "final" key word in Java.
    >
    > Why not just implement such "private" methods as functions that take a
    > "self" argument and are implemented inside an @implementation/@end
    > block ?
    >
    >
    > @implementation SomeClass
    >
    > static int _SomePrivateFunction(id self, int someArg1, NSString
    > *someArg2)
    > {
    > NSString    *tempString = [[NSString alloc] initWithFormat:@%@:%d %@,
    > [[self class] description],
    > someArg1, someArg2];
    > int                result = [tempString  length];
    >
    > [tempString release];
    >
    > return result;
    > }
    >
    >
    > - (void)somePublicMethod:(NSString *)fubar
    > {
    > static int        counter = 0;
    >
    > SomePrivateFunction(self, counter ++, fubar);
    > }
    >
    > @end
    >
    >
    > Doesn't that give you exactly what you want with the @private keyword
    > applied to methods ?
    >
    >
    >
  •   Just to add to that last note, the one other difference might be that
    the compiler would put the private method in the ObjC runtime
    information.  On the other hand, it might not put it there.  This would
    make the ObjC runtime tables a bit smaller and it would prevent access
    to private methods via objc_msgSend().  This could be good or bad
    depending upon your point of view, but it would have the nice effect of
    preventing method collision in the case that someone is trying to invoke
    private API internally via some performSelector: method.  They'd get a
    'does not recognize' error instead and would have to access the API via
    a public method (again, this could be good or bad).

    -tim

    On Wednesday, February 27, 2002, at 02:27  PM, Erik M. Buck wrote:

    > It sounds like your suggestion is that @private applied to Objective-C
    > methods should work like the "final" key word in Java.
    >
    > Why not just implement such "private" methods as functions that take a
    > "self" argument and are implemented inside an @implementation/@end
    > block ?
    >
    >
    > @implementation SomeClass
    >
    > static int _SomePrivateFunction(id self, int someArg1, NSString
    > *someArg2)
    > {
    > NSString    *tempString = [[NSString alloc] initWithFormat:@%@:%d %@,
    > [[self class] description],
    > someArg1, someArg2];
    > int                result = [tempString  length];
    >
    > [tempString release];
    >
    > return result;
    > }
    >
    >
    > - (void)somePublicMethod:(NSString *)fubar
    > {
    > static int        counter = 0;
    >
    > SomePrivateFunction(self, counter ++, fubar);
    > }
    >
    > @end
    >
    >
    > Doesn't that give you exactly what you want with the @private keyword
    > applied to methods ?
    >
    >
    >
  • The static function can access the instance variables as you describe by
    virtue of being implemented inside the @implementation block.  Try it.

    self->somePrivateVar;

    ----- Original Message -----
    From: "Timothy J. Wood" <tjw...>
    To: "Erik M. Buck" <embassociates...>
    Cc: "Kenny Leung" <kenny_leung...>; <macosx-dev...>
    Sent: Wednesday, February 27, 2002 4:21 PM
    Subject: Re: Underscore in method names

    >
    >
    > This is pretty much how the compiler would implement it, yes.  But,
    > the advantage to doing it with @private would be that the private method
    > could access private and protected ivars in the object nicely.
    >
    > -tim
    >
    >
    > On Wednesday, February 27, 2002, at 02:27  PM, Erik M. Buck wrote:
    >
    >> It sounds like your suggestion is that @private applied to Objective-C
    >> methods should work like the "final" key word in Java.
    >>
    >> Why not just implement such "private" methods as functions that take a
    >> "self" argument and are implemented inside an @implementation/@end
    >> block ?
    >>
    >>
    >> @implementation SomeClass
    >>
    >> static int _SomePrivateFunction(id self, int someArg1, NSString
    >> *someArg2)
    >> {
    >> NSString    *tempString = [[NSString alloc] initWithFormat:@%@:%d %@,
    >> [[self class] description],
    >> someArg1, someArg2];
    >> int                result = [tempString  length];
    >>
    >> [tempString release];
    >>
    >> return result;
    >> }
    >>
    >>
    >> - (void)somePublicMethod:(NSString *)fubar
    >> {
    >> static int        counter = 0;
    >>
    >> SomePrivateFunction(self, counter ++, fubar);
    >> }
    >>
    >> @end
    >>
    >>
    >> Doesn't that give you exactly what you want with the @private keyword
    >> applied to methods ?
    >>
    >>
    >>
    >
    >
    >
  •   Yoinks!  That's cool!

      I guess the only advantage to using ObjC syntax would be that it would
    be easier to pass arguments by name and it would be easier to switch
    between public/private for a method (not that that will happen too
    often).  The named arguments are sort of compelling, though.

    -tim

    On Wednesday, February 27, 2002, at 03:07  PM, Erik M. Buck wrote:

    > The static function can access the instance variables as you describe by
    > virtue of being implemented inside the @implementation block.  Try it.
    >
    > self->somePrivateVar;
    >
    > ----- Original Message -----
    > From: "Timothy J. Wood" <tjw...>
    > To: "Erik M. Buck" <embassociates...>
    > Cc: "Kenny Leung" <kenny_leung...>; <macosx-dev...>
    > Sent: Wednesday, February 27, 2002 4:21 PM
    > Subject: Re: Underscore in method names
    >
    >
    >>
    >>
    >> This is pretty much how the compiler would implement it, yes.  But,
    >> the advantage to doing it with @private would be that the private
    >> method
    >> could access private and protected ivars in the object nicely.
    >>
    >> -tim
    >>
    >>
    >> On Wednesday, February 27, 2002, at 02:27  PM, Erik M. Buck wrote:
    >>
    >>> It sounds like your suggestion is that @private applied to Objective-C
    >>> methods should work like the "final" key word in Java.
    >>>
    >>> Why not just implement such "private" methods as functions that take a
    >>> "self" argument and are implemented inside an @implementation/@end
    >>> block ?
    >>>
    >>>
    >>> @implementation SomeClass
    >>>
    >>> static int _SomePrivateFunction(id self, int someArg1, NSString
    >>> *someArg2)
    >>> {
    >>> NSString    *tempString = [[NSString alloc]
    >>> initWithFormat:@%@:%d %@,
    >>> [[self class] description],
    >>> someArg1, someArg2];
    >>> int                result = [tempString  length];
    >>>
    >>> [tempString release];
    >>>
    >>> return result;
    >>> }
    >>>
    >>>
    >>> - (void)somePublicMethod:(NSString *)fubar
    >>> {
    >>> static int        counter = 0;
    >>>
    >>> SomePrivateFunction(self, counter ++, fubar);
    >>> }
    >>>
    >>> @end
    >>>
    >>>
    >>> Doesn't that give you exactly what you want with the @private keyword
    >>> applied to methods ?
    >>>
    >>>
    >>>
    >>
    >>
    >>
    >
  • On Tuesday, February 26, 2002, at 02:33 PM, Kurt Revis wrote:

    > Yes, I know--it's my least favorite wart in practical Objective-C
    > usage.  The alternatives for naming methods (in this case, private
    > methods internal to a class's implementation, not to be used
    > externally) seem to be:
    >
    > 1) Underscore before the method name (_myMethod).  Obviously this runs
    > the risk of colliding with a method that already exists, when I am
    > subclassing someone else's object.  I can check against this in the
    > current development environment (by running class-dump on the
    > superclass and all of its superclasses), but there's still the
    > possibility that it will break in the future.
    >
    > 2) Just use plain names (myMethod).  This is a little safer--I still
    > have to check all the public methods on all superclasses but I can just
    > do that through the header files. However, I still have to do the
    > class-dump to be perfectly safe, because there are some private methods
    > which Apple doesn't prefix with an underscore (at least, there
    > historically have been).  And it still could break in the future.  (And
    > this makes it impossible to distinguish between private and public
    > methods, which is a really useful thing to be able to do at a glance.)
    >
    > 3) Prefix all methods with a hopefully-unique identifier (BLAH_myMethod
    > or something). Very safe, very ugly.

    4) Put an underscore at the *end* of the method name: myMethod_ .  We do
    this for data members in C++ classes at work, and it only seems natural
    to do the same for private methods.

        -g
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
previous month february 2002 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      
Go to today