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: Nicholas Riley <email@hidden>
- Date: Wed, 7 Aug 2002 05:18:00 -0500
- Mail-followup-to: "Michael B. Johnson" <email@hidden>, Georg Tuparev <email@hidden>, email@hidden
On Wed, Aug 07, 2002 at 12:41:35AM -0700, Michael B. Johnson wrote:
>
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?).
I don't understand the situation you're trying to describe here, but
I'll try to address what I think is your general point below.
>
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.
The scope of the discussion (and my suggested solution) was a lot
narrower: methods in your own classes shadowing methods in Apple's or
third-party frameworks which are not declared in the header files, and
causing unpredictable behavior.
Simply avoiding _ prefixes won't help: there are a number of recently
defined, private methods of public classes in AppKit (at least) which
don't use the _ convention. The first few I found were
-[NSApplication runModalForCarbonWindow:] and -[NSBitmapImageRep
imageWithoutAlpha].
Obviously the ObjC runtime is extremely flexible. I'm not suggesting
it's possible to deal with people mucking with 'isa' pointers or class
data structures at runtime. If you're writing a bundle that loads
into arbitrary applications, you have to be more careful than if
you're writing an application, as I mentioned in my previous post, and
I now realize from Bill Cheeseman's response that I probably got the
XYZ_abc method convention from looking at TextExtras.
Doing the check in the class loader would be easier, but would require
compiler changes: there would have to be some runtime-accessible tag
on a method to indicate the programmer was aware that it's overriding
a superclass method. Such a message probably shouldn't appear to a
regular user because the conflict may be innocuous, though. The "two
classes exist with this name" message does appear, and considering
there are few cases in which it's not going to cause problems, I think
it's justified.
And there are plenty of related problems that my suggested solution
won't help with at all: forgetting to look in all the superclasses'
headers before defining a method, or accidentally defining an accessor
which causes the IB runtime or key-value coding to use that method
instead of a variable. Both of these could be addressed in a
reasonably general manner by Project Builder, say the class you're
overriding or the corresponding instance variable appearing as a
contextual reminder. Doing a good job of providing useful information
for 90% of cases is better than doing nothing for 100% of them, which
is what happens now.
--
=Nicholas Riley <email@hidden> | <
http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
_______________________________________________
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.