Re: Any good advice for naming parameters of init methods?
On 11.7.2008, at 04:59, William Xu wrote: Jens Alfke [EMAIL PROTECTED] writes: With any naming convention, the possible problem is a conflict with a name in a superclass. Apple's Cocoa frameworks tend to use a _ prefix for both ivars and private method names. How about using _ as postfix then? Like `this_one_'. I find google c++ guide suggests that: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Variable_Names Looks good to me. The only disadvantage of this approach is that KVC’s direct access to your ivars_ will no longer work. KVC knows about the _ivar convention (because it is used by Apple ;-) ) and matches an _ivar to the key ivar. It won’t for ivar_. But than again it is better anyway to have explicit accessors, I’d say. Kai PS and OT: _ivar is not (any more) considered portable C++ either because all names beginning with _ are reserved for compiler/library use by the standard. -- William http://williamxu.net9.org ... I think I'd better go back to my DESK and toy with a few common MISAPPREHENSIONS ... ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/kai%40granus.net This email sent to [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Any good advice for naming parameters of init methods?
I've been always stumbling on the embarrassment of warning: local declaration of 'xxx' hides instance variable for my init methods, because I really can't figure out a nice naming pattern for parameters used to assign to instance properties, and I am always apt to write code like this: - (id)initWithURL:(NSString *)url title:(NSString *)title tags:(NSString *)tags note:(NSString *)note time:(NSString *)time count:(NSUInteger)count since it is most natural(to me). Then I just see XCode spew out lots of annoying warnings like these: Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Even though I then follow the general naming rules to prepend an indefinite article to each singular noun, I still have those plural nouns sitting there, which now looks this: - (id)initWithURL:(NSString *)aUrl title:(NSString *)aTitle tags:(NSString *)tags note:(NSString *)aNote time:(NSString *)aTime count:(NSUInteger)aCount Set aside the oddness of aTime and aCount, my XCode still complain: Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Am I supposed to use something like aGroupOfTags instead of just tags? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
On Jul 10, 2008, at 7:25 AM, an0 wrote: I've been always stumbling on the embarrassment of warning: local declaration of 'xxx' hides instance variable for my init methods, because I really can't figure out a nice naming pattern for parameters used to assign to instance properties, and I am always apt to write code like this: - (id)initWithURL:(NSString *)url title:(NSString *)title tags:(NSString *)tags note:(NSString *)note time:(NSString *)time count:(NSUInteger)count since it is most natural(to me). Then I just see XCode spew out lots of annoying warnings like these: Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Even though I then follow the general naming rules to prepend an indefinite article to each singular noun, I still have those plural nouns sitting there, which now looks this: - (id)initWithURL:(NSString *)aUrl title:(NSString *)aTitle tags:(NSString *)tags note:(NSString *)aNote time:(NSString *)aTime count:(NSUInteger)aCount Set aside the oddness of aTime and aCount, my XCode still complain: Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Am I supposed to use something like aGroupOfTags instead of just tags? someTags? I'd probably use inTags -Steve ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
Bear in mind that the names you choose for these parameter variables are unimportant really, they don't affect the public interface of your class and don't even have to match the header. What I would suggest though is that you adopt a naming convention for your instance variables (ivars) that consistently flag them as such. Some people use a leading underscore, but Apple say not to do that. I personally use 'm' (for 'member') which is a carry-over from my C++ days, but anything consistent is good. This not only fixes your shadowing problem, but makes code far more readable by indicating at a glance where a given variable lives. Graham On 11 Jul 2008, at 12:25 am, an0 wrote: I've been always stumbling on the embarrassment of warning: local declaration of 'xxx' hides instance variable for my init methods, because I really can't figure out a nice naming pattern for parameters used to assign to instance properties, and I am always apt to write code like this: - (id)initWithURL:(NSString *)url title:(NSString *)title tags:(NSString *)tags note:(NSString *)note time:(NSString *)time count:(NSUInteger)count since it is most natural(to me). Then I just see XCode spew out lots of annoying warnings like these: Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Even though I then follow the general naming rules to prepend an indefinite article to each singular noun, I still have those plural nouns sitting there, which now looks this: - (id)initWithURL:(NSString *)aUrl title:(NSString *)aTitle tags:(NSString *)tags note:(NSString *)aNote time:(NSString *)aTime count:(NSUInteger)aCount Set aside the oddness of aTime and aCount, my XCode still complain: Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Am I supposed to use something like aGroupOfTags instead of just tags? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com This email sent to [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
I like the idea of adding prefix to my ivars, and in fact, all my C++ code use _ivars. However, I like the declared properties feature of Objective-C 2.0, and the good feeling will be impaired if I have to explicitly bind ivars to these declared properties like this: @synthesize url = iUrl, title = iTitle, tags = iTags, note = iNote, time = iTime, count = iCount. It is not so bad really. But I still prefer a better naming convention for parameters if there is one. On Thu, Jul 10, 2008 at 10:38 PM, Graham Cox [EMAIL PROTECTED] wrote: Bear in mind that the names you choose for these parameter variables are unimportant really, they don't affect the public interface of your class and don't even have to match the header. What I would suggest though is that you adopt a naming convention for your instance variables (ivars) that consistently flag them as such. Some people use a leading underscore, but Apple say not to do that. I personally use 'm' (for 'member') which is a carry-over from my C++ days, but anything consistent is good. This not only fixes your shadowing problem, but makes code far more readable by indicating at a glance where a given variable lives. Graham On 11 Jul 2008, at 12:25 am, an0 wrote: I've been always stumbling on the embarrassment of warning: local declaration of 'xxx' hides instance variable for my init methods, because I really can't figure out a nice naming pattern for parameters used to assign to instance properties, and I am always apt to write code like this: - (id)initWithURL:(NSString *)url title:(NSString *)title tags:(NSString *)tags note:(NSString *)note time:(NSString *)time count:(NSUInteger)count since it is most natural(to me). Then I just see XCode spew out lots of annoying warnings like these: Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:28: warning: local declaration of 'url' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:29: warning: local declaration of 'title' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:32: warning: local declaration of 'time' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Even though I then follow the general naming rules to prepend an indefinite article to each singular noun, I still have those plural nouns sitting there, which now looks this: - (id)initWithURL:(NSString *)aUrl title:(NSString *)aTitle tags:(NSString *)tags note:(NSString *)aNote time:(NSString *)aTime count:(NSUInteger)aCount Set aside the oddness of aTime and aCount, my XCode still complain: Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Line Location Post.m:30: warning: local declaration of 'tags' hides instance variable Am I supposed to use something like aGroupOfTags instead of just tags? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com This email sent to [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
On 10 Jul '08, at 8:09 AM, an0 wrote: I like the idea of adding prefix to my ivars, and in fact, all my C++ code use _ivars. Good! I highly recommend that in Obj-C too. (I use _ like you.) However, I like the declared properties feature of Objective-C 2.0, and the good feeling will be impaired if I have to explicitly bind ivars to these declared properties like this: @synthesize url = iUrl, title = iTitle, tags = iTags, note = iNote, time = iTime, count = iCount. *shrug* I don't find it much of a problem. It's just a few more characters to type in the .m file for each property, and it has no effect on clients of that class. As I said, I highly recommend using ivar prefixes. —Jens 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
I'd probably use inTags I'll add my vote for this. I've seen it used many places. With respect, though, I think the OP may be a bit confused about the concept of 'scope': Am I supposed to use something like aGroupOfTags instead of just tags? This is why I suspect a conceptual problem. -- I.S. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
On 10 Jul '08, at 8:52 AM, Sean McBride wrote: On 7/11/08 12:38 AM, Graham Cox said: What I would suggest though is that you adopt a naming convention for your instance variables (ivars) that consistently flag them as such. Some people use a leading underscore, but Apple say not to do that. Do the docs still say that? We've had this discussion before: http://www.cocoabuilder.com/archive/message/cocoa/2008/4/3/203159 With any naming convention, the possible problem is a conflict with a name in a superclass. Apple's Cocoa frameworks tend to use a _ prefix for both ivars and private method names. Method-name conflicts are very bad and will cause trouble at runtime. The worst case is where Apple adds a method, in a new release of the OS, which has the same name as one of your methods. This will probably cause your app to break because when the framework calls that private method, it gets your implementation instead. Ivar-name conflicts are, IIRC, a lot less harmful. For the most part, ivar names are used only at compile time (the generated code just accesses ivars by a byte offset from the object) so the effect in the above situation will be that your app continues to work fine, but when you try to recompile the app using the SDK for the new OS, you'll get a compile error about a duplicate ivar name. Then you just rename yours. Someone did bring up the issue of dynamic ivar-name lookups. KVC sometimes uses these. It's possible there could be runtime problems in this case, although I'm not sure. All I can say is that I've been using the _ prefix in my code for almost eight years now without running into such problems. —Jens 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
On Jul 10, 2008, at 11:06 AM, Jens Alfke wrote:
On 10 Jul '08, at 8:52 AM, Sean McBride wrote:
On 7/11/08 12:38 AM, Graham Cox said:
What I would suggest though is that you adopt a naming convention
for
your instance variables (ivars) that consistently flag them as such.
Some people use a leading underscore, but Apple say not to do that.
Do the docs still say that? We've had this discussion before:
http://www.cocoabuilder.com/archive/message/cocoa/2008/4/3/203159
With any naming convention, the possible problem is a conflict with
a name in a superclass.
Apple's Cocoa frameworks tend to use a _ prefix for both ivars and
private method names.
Method-name conflicts are very bad and will cause trouble at
runtime. The worst case is where Apple adds a method, in a new
release of the OS, which has the same name as one of your methods.
This will probably cause your app to break because when the
framework calls that private method, it gets your implementation
instead.
Ivar-name conflicts are, IIRC, a lot less harmful. For the most
part, ivar names are used only at compile time (the generated code
just accesses ivars by a byte offset from the object) so the effect
in the above situation will be that your app continues to work fine,
but when you try to recompile the app using the SDK for the new OS,
you'll get a compile error about a duplicate ivar name. Then you
just rename yours.
Someone did bring up the issue of dynamic ivar-name lookups. KVC
sometimes uses these. It's possible there could be runtime problems
in this case, although I'm not sure. All I can say is that I've been
using the _ prefix in my code for almost eight years now without
running into such problems.
The problem is that while when you recompile you'll see the conflict,
for existing users (who won't be compiling from source), if they use
KVC they'll have the problem.
@interface NSFoo {
id _reserved;
}
@end
@interface MyFoo: NSFoo {
float _value;
}
@end
And OS X+1 comes out with:
@interface NSFoo {
int _value;
}
@end
Any of your code that used _value (like, say, for bindings) could
suddenly break for users of OS X N+ 1 (since they won't be compiling
from source to see what is going on).
Granted, it's rare that this happens, but from time to time reserved
fields do get converted to something used. And lets face it, if you
hear it works fine on OS X N, but breaks on OS X N+1, ivar
collision isn't the first thing you'll think about to try to track
down the problem...
Worse, this could actually happen on an OS X N+ 0.1 release and the
headers wouldn't get updated so you won't even have the safety net of
seeing compiler errors. Similarly, if you target the OS X N SDK, you
won't see the new headers either.
Haven't run into such problems != Such problems don't happen
Glenn Andreas [EMAIL PROTECTED]
http://www.gandreas.com/ wicked fun!
JSKit | the easy way to unite JavaScript and Objective C
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
[OT] Re: Any good advice for naming parameters of init methods?
If you have a property value in your subclass (using the term
'property' loosely, not in the Objective-C 2.0 sense), and Apple adds
the property value to the superclass, you're probably going to be
hosed in one way or another. For example, if Apple adds the _value
ivar, they're also likely to add -value and -setValue: methods, in
which case relying on KVC to find your ivar is going to fail when it
finds Apple's accessors. You could avoid that by implementing your
own accessors, but then Apple's code might contain calls to those
accessors that expect to find Apple's implementation (or a superclass-
aware subclass implementation) rather than your own superclass-
ignorant implementation.
Such are the hazards of subclassing, I think.
-Jeff
On Jul 10, 2008, at 11:19 AM, glenn andreas wrote:
The problem is that while when you recompile you'll see the
conflict, for existing users (who won't be compiling from source),
if they use KVC they'll have the problem.
@interface NSFoo {
id _reserved;
}
@end
@interface MyFoo: NSFoo {
float _value;
}
@end
And OS X+1 comes out with:
@interface NSFoo {
int _value;
}
@end
Any of your code that used _value (like, say, for bindings) could
suddenly break for users of OS X N+ 1 (since they won't be
compiling from source to see what is going on).
Granted, it's rare that this happens, but from time to time
reserved fields do get converted to something used. And lets face
it, if you hear it works fine on OS X N, but breaks on OS X N+1,
ivar collision isn't the first thing you'll think about to try to
track down the problem...
Worse, this could actually happen on an OS X N+ 0.1 release and the
headers wouldn't get updated so you won't even have the safety net
of seeing compiler errors. Similarly, if you target the OS X N
SDK, you won't see the new headers either.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
On Jul 10, 2008, at 11:19 AM, glenn andreas wrote:
The problem is that while when you recompile you'll see the
conflict, for existing users (who won't be compiling from source),
if they use KVC they'll have the problem.
@interface NSFoo {
id _reserved;
}
@end
@interface MyFoo: NSFoo {
float _value;
}
@end
And OS X+1 comes out with:
@interface NSFoo {
int _value;
}
@end
Any of your code that used _value (like, say, for bindings) could
suddenly break for users of OS X N+ 1 (since they won't be compiling
from source to see what is going on).
Granted, it's rare that this happens, but from time to time reserved
fields do get converted to something used. And lets face it, if you
hear it works fine on OS X N, but breaks on OS X N+1, ivar
collision isn't the first thing you'll think about to try to track
down the problem...
Worse, this could actually happen on an OS X N+ 0.1 release and the
headers wouldn't get updated so you won't even have the safety net
of seeing compiler errors. Similarly, if you target the OS X N SDK,
you won't see the new headers either.
Haven't run into such problems != Such problems don't happen
I definitely got burned by this myself a few years back (when the
NSAnimation API was added). I didn't use that class at all, but got
very strange runtime issues with an NSCell subclass of mine. One of
the cell's ivars name collided with NSAnimation. And, in code like
this:
[[self cell] foo];
Since, [self cell] returns id, it ended up thinking that the return
object was actually an NSAnimation instance and not my cell.
From that point onwards, I've renamed all my classes, ivars, binding
names, keys, etc. to use a custom prefix/suffix of II (company name).
Details of this approach can be found in the archives.
___
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm) http://www.instantinteractive.com
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Any good advice for naming parameters of init methods?
Jens Alfke [EMAIL PROTECTED] writes: With any naming convention, the possible problem is a conflict with a name in a superclass. Apple's Cocoa frameworks tend to use a _ prefix for both ivars and private method names. How about using _ as postfix then? Like `this_one_'. I find google c++ guide suggests that: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Variable_Names Looks good to me. -- William http://williamxu.net9.org ... I think I'd better go back to my DESK and toy with a few common MISAPPREHENSIONS ... ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
