Re: Setting focus to text field in drawer
Re: Setting focus to text field in drawer
- Subject: Re: Setting focus to text field in drawer
- From: Bill Cheeseman <email@hidden>
- Date: Mon, 11 Aug 2003 06:26:44 -0400
on 03-08-11 12:04 AM, publiclook at email@hidden wrote:
>
> Um. Instance variable names are local to their class, no? So what's
>
> the point of trying to avoid collisions here?
>
>
>
> More care is needed with class names though. :}
>
>
>
>
A quick search of this lists archives reveals the following post from
>
Apple's Ali Ozer:
>
http://cocoa.mamasam.com/MACOSXDEV/2002/02/2/26587.php
>
>
This folk-lore (which happens to be true) comes up a couple of times
>
per year.
Notice that Ali's post refers only to Apple's reserving METHOD names with a
leading underscore. INSTANCE VARIABLE names are different. I originally ran
across this rule in a post from Apple's Mike Ferris almost three years ago,
which I will quote at the end of this message.
By the way, there is a good reason to use a leading underscore with instance
variable names. The key-value coding protocol, which is used in many ways in
Cocoa, will look for instance variables both with and without a leading
underscore when it can't find an accessor method with the same name. The
value of the leading underscore is in avoiding naming conflicts within your
own setter accessor methods, while still giving you the benefits of
key-value coding. For example:
- (void)setMyVar:(id)myVar {
myVar = myVar;
}
doesn't work, but this does:
- (void)setMyVar:(id)myVar {
_myVar = myVar;
}
Without the leading underscore on the iVar name, you have to resort to
naming the parameter "theMyVar" or "aMyVar", which you see in a lot of code
examples but which I personally find distasteful. (Somebody correct me if
I've got the example wrong, as I'm working from memory.)
Here's the Mike Ferris post, from November 2000:
"Here's one that may generate controversy...
"Prefixing methods with "_" to indicate private methods is reserved for
Apple's use. Same goes for exported functions (for static functions, go
nuts).
"If everyone uses this "_" convention it is bad because subclasses can
override an existing private method with one of their own without knowing
it. This could obviously wind up having really nasty consequences.
"In my own non-Apple code, I try to make private methods start with
"<Prefix>_" where <Prefix> is the prefix I am using for that project like
"TE" for TextExtras. Yes, it is ugly to have methods like
TE_myPrivateMethod:, but it is only ugly internally since they are private
methods.
"Now, for ivars, this is less of an issue since I am pretty sure the
compiler will complain if you wind up duplicating an ivar name from one of
your ancestor classes."
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
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.