Re: enough of accessors - how about private method naming conventions in the real world?
Re: enough of accessors - how about private method naming conventions in the real world?
- Subject: Re: enough of accessors - how about private method naming conventions in the real world?
- From: "Timothy J. Wood" <email@hidden>
- Date: Wed, 7 Aug 2002 09:48:09 -0700
On Tuesday, August 6, 2002, at 10:48 PM, Michael B. Johnson wrote:
So we all know that Apple has coopted the "prefix your private methods
with an underscore" idiom, and told us not to use it. Annoyingly
enough, this is fair, since we don't have source to the Apple
frameworks, and since any private methods one might implement using the
same naming convention would silently override their particular
implementation, leading to all sorts of nasty, hard to find bugs.
I've been bit by this bug exactly once since NEXTSTEP 0.9. This was
with some method defined in EOF on NSMutableArray that did NOT have
the '_', but wasn't declared public. This was just an obvious utility
method that EOF added for its own purposes (and had a different return
type than our version or something like that).
Thus, it seems that Apple doesn't follow their own rule here (witness
other examples people have mentioned of this).
At any rate, no, this doesn't seem fair. If Apple is going to
mandate a syntactic form of namespaces, they should (a) follow the rule
and (b) not take the easiest version for themselves. If Apple used the
most strict version (like, maybe,
_com_apple_FrameworkName_CategoryName_myMethod), then developers writing
apps could use '_' and only bundle/framework developers would need to do
the ugly version.
Cocoa is supposed to be about making it "N times easier to develop
applications" -- stuff like this erodes that position. It should be
Apple's job to maintain that position, not to make all their developers
do a bunch of tedious work. There are lots of reasons for them to keep
using '_' themselves (the inertia of how ever many million lines of
Cocoa code they have comes to mind...), but in an idea world, they'd
switch to this rule internally.
As to what I do about this problem. My approach is threefold:
1) Bury head in sand
2) Complain about Apple not solving the problem for us
3) Contemplate adding support to gcc in some fashion that would
solve this (perhaps support for statically bound private methods)
4) Get back to work
This isn't a very effective strategy, though :)
-tim
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.