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
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 go
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: NSFo
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 lik
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
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 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 discu
> 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: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
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, titl
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) th
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 alw
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)ini
13 matches
Mail list logo