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
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:
-
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
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)
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
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
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.
--
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.
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
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
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:
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++
12 matches
Mail list logo
