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: "Michael B. Johnson" <email@hidden>
- Date: Wed, 07 Aug 2002 00:41:35 -0700
On Wednesday, August 7, 2002, at 12:29 AM, Nicholas Riley wrote:
On Wed, Aug 07, 2002 at 09:22:59AM +0200, Georg Tuparev wrote:
What I ended up is a shell script (kind of integrated with emacs) that
makes class dump and looks for overridden methods. At the moment the
script is very dumb and reports also methods from the public API and
methods that explicitly call super's implementation - so I really use
this before code frees, new Dev Tools release and if my programs start
behaving strangely. But one day (hopefully one_day <<
NSDistantFuture ;-) I will improve this script so that I can make it a
post-compile build phase....
I wonder if it would be hard to do this as part of compilation? You
could have a compiler warning something like 'method XYZ shadows
private method implemented in superclass NSABC', and a pragma to
disable it on a per-method basis if you really know what you're doing.
no, no, no, no, no (I know most of you know the following, but for some
of those following at home...)
you can (and the compiler does) do you this for instance variables, but
*by definition*, the compiler cannot do this for you for methods. This
is one of the fundamental misconceptions of Obj-C vs. C++, in my
experience.
I can (and do) have methods that exist for my classes in one app (say
InterfaceBuilder) that do not exist in an app that links against the
very same framework (i.e. - (NSString *)inspectorClassName only exists
in a category of the class that is implemented in the IB palette that
uses that framework - there is no good reason to have it be part of the
framework, right?).
It is a feature (and an unavoidable bug :-/ - actually, the point of
this discussion is to figure out how to avoid it) that anyone, at
anytime, can add methods to your class (or the superclass of the class
you inherit from) in Objective-C.
ah, the wonder and weirdness of run-time binding.
--> Michael B. Johnson, Ph.D. -- email@hidden
--> Studio Tools, Pixar Animation Studios
-->
http://xenia.media.mit.edu/~wave
_______________________________________________
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.