My own preference is to prefix private methods with underscores and the project’s class prefix. For example, from source code of WebUIKit (class prefix CGI, taken from its parent project CGIKit):
NSString *const k_CGI_PrivateMemberAttribute;
@interface CGIView ()
+ (id)_CGI_superviewWithClass:(Class)class;
@end
I believe there will be no chance for private method names clashing any more
unless someone inheriting my class decided to keep using the CGI prefix (which
is stupid in the first place) and keep my private method naming convention.
Or you can refactor your private methods into functions with
CoreFoundation-like argument lists, like this (from source code of Kaleidoscope
Event Engine, class prefix KLS):
void _KLS_RunLoopExecute(void *info) // Use self as
CFRunLoopSourceContext->info and CoreFoundation object memory management
functions otherwise, so I can cast pointers
{
KLSRunLoopSource *self = (__bridge KLSRunLoopSource *)info; // I am working
with CoreFoundation which takes void pointers here. You can get away without
this cast by putting "KLSRunLoopSource *self” equivalent directly to the
argument list.
[self execute];
}
> On Aug 18, 2015, at 22:58, Richard Charles <rcharles...@gmail.com> wrote:
>
> Apple documentation states that the "Names of most private methods in the
> Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark
> them as private.”
>
> I just ran into a case where one of my method names in a subclass replaced a
> private Cocoa framework method of the same name causing my application to
> crash in the next version of OS X. The private Cocoa framework method name
> did not have an underscore prefix. So the documentation is correct, “most”
> but not all private methods in the frameworks have an underscore prefix.
>
> There is no way that I would have known about the private Cocoa framework
> method except examining a class-dump.
>
> Apple documentation also states that "If you are subclassing a large Cocoa
> framework class (such as NSView or UIView) and you want to be absolutely sure
> that your private methods have names different from those in the superclass,
> you can add your own prefix to your private methods. The prefix should be as
> unique as possible, perhaps one based on your company or project and of the
> form "XX_". So if your project is called Byte Flogger, the prefix might be
> BF_addObject:"
>
> I have never bothered doing this because for one reason BF_addObject looks so
> ugly as a method name.
>
> Does anyone prefix their private method names like Apple recommends when
> subclassing a large Cocoa framework class?
>
> Also why does Apple say "If you are subclassing a large Cocoa framework
> class”. What if I am subclassing a small Cocoa framework class. What
> difference would it make?
>
> --Richard Charles
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/max%40maxchan.info
>
> This email sent to m...@maxchan.info
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
