Re: A Data Object in Cocoa
On Jan 10, 2009, at 11:48 PM, Michael Ash wrote: Except that if Apple renames one of their ivars to match the name of one of your subclass's ivars nothing happens. You don't crash, you don't misbehave. Everything continues on like usual. Unlike methods, ivars are *not* looked up by name, but rather by offset. Not true under 64 bit Objective-C 2.0 (nor the iPhone's 32 bit Objective-C 2.0) which do not use an offset. And under those modern platforms, Apple doesn't even have to rename an ivar - they can freely add new ivars to the base class, which increases the chance of this collision (instead of just being limited to the rename of an existing reserved ivar). The question, of course, is what happens when a super class in a framework adds an ivar whose name collides with an existing subclass's ivar is probably a question for Greg Parker... If the ivar key is based on the ivar name + class where the compiler saw the ivar was declared, everything is good. If it is just ivar name, problems. Perhaps this discussion should be taken to the Objective-C mailing list. Glenn Andreas gandr...@gandreas.com http://www.gandreas.com/ wicked fun! quadrium2 | build, mutate, evolve, animate | images, textures, fractals, art ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sun, Jan 11, 2009 at 10:08 AM, glenn andreas gandr...@mac.com wrote: On Jan 10, 2009, at 11:48 PM, Michael Ash wrote: Except that if Apple renames one of their ivars to match the name of one of your subclass's ivars nothing happens. You don't crash, you don't misbehave. Everything continues on like usual. Unlike methods, ivars are *not* looked up by name, but rather by offset. Not true under 64 bit Objective-C 2.0 (nor the iPhone's 32 bit Objective-C 2.0) which do not use an offset. And under those modern platforms, Apple doesn't even have to rename an ivar - they can freely add new ivars to the base class, which increases the chance of this collision (instead of just being limited to the rename of an existing reserved ivar). The question, of course, is what happens when a super class in a framework adds an ivar whose name collides with an existing subclass's ivar is probably a question for Greg Parker... If the ivar key is based on the ivar name + class where the compiler saw the ivar was declared, everything is good. If it is just ivar name, problems. A quick bit of testing reveals that the linker symbol looks like this: _OBJC_IVAR_$_MyClass.myClassIvar And so there will be no problem with matching names in the class hierarchy. Perhaps this discussion should be taken to the Objective-C mailing list. I think it fits well here, given that much of the discussion is based around recommendations for names in Cocoa programs which wouldn't necessarily hold for non-Cocoa ObjC programs. Mike ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
Thanks for all your responses. I am indeed using synthesized properties which hopefully will free me from having to do play around with retain/release. How anyone can get any work done without an automatic GC is unclear to me - you guys are hard core ;) Prior to embarking on Cocoa development, I was sceptical about the garbage collector - like, it's still very much possible to create memory leaks. It's not the end of memory leaks, as the Java docs made it out to be. However, now that I am without it, I can fully appreciate how great it really is ;) I am just going to use the aParameter naming scheme, since that seems to be the standard. The trick with naming the member variable _memberVar is a little bit too clever for me, I think ;) Nik ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On 10 Jan 2009, at 00:11, Adam Foltzer wrote: I've noticed a pattern in some Apple code where the instance variables are all prefixed with an underscore, but the property name, and therefore the accessors, are what you'd expect. Except that there's a long-standing rule that we shouldn't use leading underscores for either member variable names or private method names because names beginning with underscore are reserved for Apple's own use (even member variable names, IIRC). So if you're going to use a prefix, it's probably best to pick something like m (for member). But in general I think it's better not to prefix the names of member variables, and then in your initialisers, to use a different name for the argument. Kind regards, Alastair. -- http://alastairs-place.net ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On 10 Jan 2009, at 00:40, Kyle Sluder wrote:
On Fri, Jan 9, 2009 at 7:11 PM, Adam Foltzer acfolt...@gmail.com
wrote:
- (id)initWithInt:(int)foo
{
if (![super init])
return nil;
[self setFoo:foo];
return self;
}
Do not use getters and setters in -init. You should be accessing the
ivars directly.
While we're on this topic, I think a more important problem with the
above is the assumption that [super init] either returns nil or the
current value of self.
It should of course be
if ((self = [super init])) {
// Initialise
}
return self;
or some equivalent construct.
Kind regards,
Alastair.
--
http://alastairs-place.net
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Jan 10, 2009, at 6:45 AM, Alastair Houghton wrote:
On 10 Jan 2009, at 00:11, Adam Foltzer wrote:
I've noticed a pattern in some Apple code where the instance
variables are
all prefixed with an underscore, but the property name, and
therefore the
accessors, are what you'd expect.
Except that there's a long-standing rule that we shouldn't use
leading underscores for either member variable names or private
method names because names beginning with underscore are reserved
for Apple's own use (even member variable names, IIRC). So if
you're going to use a prefix, it's probably best to pick something
like m (for member).
But in general I think it's better not to prefix the names of member
variables, and then in your initialisers, to use a different name
for the argument.
My personal pattern is to leave the ivars as-is. Then, for
parameters, I prefix with 'a' or 'an'. Local variables are prefixed
with 'the':
'value' is the name of the ivar...
- (void)incrementBy:(int)aValue
{
int theOldValue = value;
value = aValue;
if (aValue != theOldValue)
...
}
___
Ricky A. Sharp mailto:rsh...@instantinteractive.com
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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
On Sat, Jan 10, 2009 at 12:56 AM, Andrew Farmer andf...@gmail.com wrote: Not to mention, there is no guarantee that future versions of the compiler will behave identically when processing code that generates warnings. It is not uncommon for warnings to later turn into errors, or (worse!) incorrect behavior, especially when optimizations are involved. Just to pick a nit, this depends greatly on what the warning is about. A lot of warnings are actually about code whose behavior is fully specified by the standard but which is still considered to be iffy. For example, writing if(a = b) will generate a warning under -Wall but its behavior is fully specified and cannot change in any conforming compiler. However it's still a good idea to fix them, and many warnings *are* about code whose behavior could change. Mike ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sat, Jan 10, 2009 at 7:45 AM, Alastair Houghton alast...@alastairs-place.net wrote: On 10 Jan 2009, at 00:11, Adam Foltzer wrote: I've noticed a pattern in some Apple code where the instance variables are all prefixed with an underscore, but the property name, and therefore the accessors, are what you'd expect. Except that there's a long-standing rule that we shouldn't use leading underscores for either member variable names or private method names because names beginning with underscore are reserved for Apple's own use (even member variable names, IIRC). So if you're going to use a prefix, it's probably best to pick something like m (for member). But in general I think it's better not to prefix the names of member variables, and then in your initialisers, to use a different name for the argument. Personally I have found that prefixing my instance variables is one of the best things I've ever done for code clarity. Being able to instantly tell that a particular variable is an instance variable or not is extremely valuable, at least to me. Tastes may vary. As for underscore being reserved, I have never been able to figure out any consequence of a conflict with an Apple ivar name. It may cause your source to fail to compile, but it won't cause any *binary* compatibility problems, which is the real menace. Mike ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On 10 Jan 2009, at 16:48, Michael Ash wrote: As for underscore being reserved, I have never been able to figure out any consequence of a conflict with an Apple ivar name. It may cause your source to fail to compile, but it won't cause any *binary* compatibility problems, which is the real menace. I *think* the problem here is introspection... if you subclass an Apple provided class and add an instance variable with the same name as one of theirs, it's possible that any of the dynamic mechanisms the frameworks (or, for that matter, your own code) use to get the value of an object property might use the wrong variable, with unexpected results. Kind regards, Alastair. -- http://alastairs-place.net ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sat, Jan 10, 2009 at 12:08 PM, Alastair Houghton alast...@alastairs-place.net wrote: On 10 Jan 2009, at 16:48, Michael Ash wrote: As for underscore being reserved, I have never been able to figure out any consequence of a conflict with an Apple ivar name. It may cause your source to fail to compile, but it won't cause any *binary* compatibility problems, which is the real menace. I *think* the problem here is introspection... if you subclass an Apple provided class and add an instance variable with the same name as one of theirs, it's possible that any of the dynamic mechanisms the frameworks (or, for that matter, your own code) use to get the value of an object property might use the wrong variable, with unexpected results. Not using an underscore won't save you here. Mechanisms like KVC will look for ivars both with and without the underscore. In fact, leaving off the underscore makes things worse: with the underscore, the compiler will at least error when you try to recompile later on, whereas without it the conflict will exist silently. A cow-orker just pointed out to me that Apple does not, in fact, recommend against an underscore prefix for instance variables. They do recommend against them for private methods, but that's a completely different question. It seems that the well-known recommendation against _ivars is actually a misconception! If I'm wrong and just missed it, I'd like to know where it says so. But no trace of such a recommendation in Coding Guidelines for Cocoa: Naming Instance Variables and Data Types: http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284 Mike ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sat, Jan 10, 2009 at 12:39 PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: On 10 Jan 2009, at 17:18, Michael Ash wrote: On Sat, Jan 10, 2009 at 12:08 PM, Alastair Houghton alast...@alastairs-place.net wrote: On 10 Jan 2009, at 16:48, Michael Ash wrote: As for underscore being reserved, I have never been able to figure out any consequence of a conflict with an Apple ivar name. It may cause your source to fail to compile, but it won't cause any *binary* compatibility problems, which is the real menace. I *think* the problem here is introspection... if you subclass an Apple provided class and add an instance variable with the same name as one of theirs, it's possible that any of the dynamic mechanisms the frameworks (or, for that matter, your own code) use to get the value of an object property might use the wrong variable, with unexpected results. Not using an underscore won't save you here. Mechanisms like KVC will look for ivars both with and without the underscore. In fact, leaving off the underscore makes things worse: with the underscore, the compiler will at least error when you try to recompile later on, whereas without it the conflict will exist silently. A cow-orker just pointed out to me that Apple does not, in fact, recommend against an underscore prefix for instance variables. They do recommend against them for private methods, but that's a completely different question. It seems that the well-known recommendation against _ivars is actually a misconception! If I'm wrong and just missed it, I'd like to know where it says so. But no trace of such a recommendation in Coding Guidelines for Cocoa: Naming Instance Variables and Data Types: http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284 For what it's worth Anguish et al states (p99) that Apple reserves the right to change private instance variables that begin with an underscore and no prefix. Anguish et al recommend and _ + unique prefix for ivars. I don't have whichever book you're referring to so I can't see what it actually says, but your summary makes no sense. Apple can't change *your* ivars. If it means they reserve the right to change their own private instance variables that begin with an underscore and no prefix, well of course, that's what private means. That's why you should never directly twiddle another class's ivars. But that has nothing to do with how you should name your own ivars. Mike ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Saturday, January 10, 2009, at 12:39PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: For what it's worth Anguish et al states (p99) that Apple reserves the right to change private instance variables that begin with an underscore and no prefix. On Saturday, January 10, 2009, at 02:40PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: I agree that it is confusing, or meaningless, but I thought it might have contributed to the _ misconception. A Google for - anguish underscores and usage - will show the passage I referred to. It sounds like the risk is that Apple could rename one of their _ivars so the new name collides with one of your _ivars that previously was okay. You would quickly discover this the next time you compile, but I assume existing users of your app would find it suddenly crashes after their last OS update. Anguish et al. recommend mitigating this risk by using a unique prefix in addition to the underscore. I personally don't worry too much about it. I doubt Apple would change the name of an ivar from _forFutureUse13 to _name. --Andy ___ 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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
Michael Ash (michael@gmail.com) on 2009-01-10 11:46 AM said: However it's still a good idea to fix them, and many warnings *are* about code whose behavior could change. Then there is the annoying situation of a warning that is in general very useful, but sometimes warns in cases where you really don't want it to. My favourite example is when Cocoa has two methods with the same name that return different types. Like -(NSRect)frame vs -(CGRect)frame, or - (id)window vs -(NSWindow*)window, or -(NSUInteger)count vs -(size_t)count. For example: NSArrayController* controller = nil; NSUInteger c = [[controller arrangedObjects] count]; gives warning: multiple methods named '-count' found :( Sean ___ 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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
On Sat, Jan 10, 2009 at 6:20 PM, Sean McBride cwat...@cam.org wrote: Michael Ash (michael@gmail.com) on 2009-01-10 11:46 AM said: My favourite example is when Cocoa has two methods with the same name that return different types. Like -(NSRect)frame vs -(CGRect)frame, or - (id)window vs -(NSWindow*)window, or -(NSUInteger)count vs -(size_t)count. If both methods don't return the same kind of thing (scalar vs. struct vs. float) then your program might go kablooey. --Kyle Sluder ___ 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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
On 10 Jan 09, at 08:46, Michael Ash wrote: Just to pick a nit, this depends greatly on what the warning is about. A lot of warnings are actually about code whose behavior is fully specified by the standard but which is still considered to be iffy. For example, writing if(a = b) will generate a warning under -Wall but its behavior is fully specified and cannot change in any conforming compiler. However it's still a good idea to fix them, and many warnings *are* about code whose behavior could change. Excellent point. As you mention, though, it's usually best to just work around these sorts of warnings (in this case, with an extra set of parentheses), as it's quite common that this sort of code *is* a mistake on the part of the author. :) On 10 Jan 09, at 15:20, Sean McBride wrote: Then there is the annoying situation of a warning that is in general very useful, but sometimes warns in cases where you really don't want it to. My favourite example is when Cocoa has two methods with the same name that return different types. Like -(NSRect)frame vs -(CGRect)frame, or - (id)window vs -(NSWindow*)window, or -(NSUInteger)count vs - (size_t)count. For example: NSArrayController* controller = nil; NSUInteger c = [[controller arrangedObjects] count]; gives warning: multiple methods named '-count' found :( You can silence this one by casting the return value of the inner method to a more specific type. In this case, the fix is: NSUInteger c = [(NSArray *)[controller arrangedObjects] count]; As Kyle Sluder mentions, this warning has the potential to generate incorrect code, so the warning is entirely appropriate. ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Sat, Jan 10, 2009 at 3:33 PM, Andy Lee ag...@mac.com wrote: On Saturday, January 10, 2009, at 12:39PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: For what it's worth Anguish et al states (p99) that Apple reserves the right to change private instance variables that begin with an underscore and no prefix. On Saturday, January 10, 2009, at 02:40PM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: I agree that it is confusing, or meaningless, but I thought it might have contributed to the _ misconception. A Google for - anguish underscores and usage - will show the passage I referred to. It sounds like the risk is that Apple could rename one of their _ivars so the new name collides with one of your _ivars that previously was okay. You would quickly discover this the next time you compile, but I assume existing users of your app would find it suddenly crashes after their last OS update. Anguish et al. recommend mitigating this risk by using a unique prefix in addition to the underscore. Except that if Apple renames one of their ivars to match the name of one of your subclass's ivars nothing happens. You don't crash, you don't misbehave. Everything continues on like usual. Unlike methods, ivars are *not* looked up by name, but rather by offset. (This is no longer true if you're using KVC direct ivar access but, well, just another reason why you shouldn't do that.) Mike ___ 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 arch...@mail-archive.com
A Data Object in Cocoa
I am trying to define a pure data object in Cocoa. This object doesn't
do anything, it should just act as a container for three strings. This
is generally a good design pattern, at least in Java.
In Cocoa, I am running into a lot of resistance. The constructor is
rather complicated.
And the compiler complains about this:
- (id)initWithLabel:(NSString *)label pin:(NSString *)pin seed:
(NSString *)seed {
if (self = [super init]) {
self.label = label; ///--- compiler complains
self.pin = pin;
self.seed = seed;
}
return self;
}
I get three warnings that say local declaration of x overrides
instance variables. I thought I could differentiate between the
parameters and the instance variables using self.variable vs just
variable.
What's the Cocoa way of doing this? Do I really have to name the
parameters pLabel, pSeed, and pPin? Or would it be better to just keep
that stuff in a Dictionary object?
Thanks for any help,
Nik
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
Hi Nik,
self is a pointer, so you might want to change self. into self-
I usually prefix arguments with an 'a' (a for Argument):
- (id)initWithLabel:(NSString *)aLabel pin:(NSString *)aPin seed:
(NSString *)aSeed
{
self = [super init];
if(self)
{
label = aLabel;
pin = aPin;
seed = aSeed;
}
return(self);
}
However, if you do the above, you'll most likely run into problems
regarding autoreleased objects.
Instead, you should...
label = [aLabel retain];
pin = [aPin retain];
seed = [aSeed retain];
And your -dealloc method:
- (void)dealloc
{
[seed release];
[pin release];
[label release];
[super dealloc];
}
You may prefer having setters and getters:
- (void)setLabel:(NSString *)aLabel
{
[aLabel retain];
[label release];
label = aLabel;
}
- (NSString *)label
{
return(label);
}
Then you could simply use the much more 'in order':
- (id)initWithLabel:(NSString *)aLabel pin:(NSString *)aPin seed:
(NSString *)aSeed
{
self = [super init];
if(self)
{
[self setLabel:aLabel];
[self setPin:aPin];
[self setSeed:aSeed];
}
return(self);
}
- (void)dealloc
{
[self setSeed:NULL];
[self setPin:NULL];
[self setLabel:NULL];
[super dealloc];
}
Love,
Jens
On Jan 9, 2009, at 08:49, nik heger wrote:
I am trying to define a pure data object in Cocoa. This object
doesn't do anything, it should just act as a container for three
strings. This is generally a good design pattern, at least in Java.
In Cocoa, I am running into a lot of resistance. The constructor is
rather complicated.
And the compiler complains about this:
- (id)initWithLabel:(NSString *)label pin:(NSString *)pin seed:
(NSString *)seed {
if (self = [super init]) {
self.label = label; ///--- compiler complains
self.pin = pin;
self.seed = seed;
}
return self;
}
I get three warnings that say local declaration of x overrides
instance variables. I thought I could differentiate between the
parameters and the instance variables using self.variable vs just
variable.
What's the Cocoa way of doing this? Do I really have to name the
parameters pLabel, pSeed, and pPin? Or would it be better to just
keep that stuff in a Dictionary object?
Thanks for any help,
Nik
___
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/jensbauer%40christian.net
This email sent to jensba...@christian.net
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
the compiler is complaining just because they all have the same name
and he is confused about witch to choose
to resolve the issue, just rename the parameters of your procedure.
IE: - (id)initWithLabel:(NSString *)initLabel pin:(NSString *)initPin
seed:(NSString *)initSeed {
or whatever name that makes them different than your classe's
definition.
Sandro Noel..
On 9-Jan-09, at 2:49 AM, nik heger wrote:
I am trying to define a pure data object in Cocoa. This object
doesn't do anything, it should just act as a container for three
strings. This is generally a good design pattern, at least in Java.
In Cocoa, I am running into a lot of resistance. The constructor is
rather complicated.
And the compiler complains about this:
- (id)initWithLabel:(NSString *)label pin:(NSString *)pin seed:
(NSString *)seed {
if (self = [super init]) {
self.label = label; ///--- compiler complains
self.pin = pin;
self.seed = seed;
}
return self;
}
I get three warnings that say local declaration of x overrides
instance variables. I thought I could differentiate between the
parameters and the instance variables using self.variable vs just
variable.
What's the Cocoa way of doing this? Do I really have to name the
parameters pLabel, pSeed, and pPin? Or would it be better to just
keep that stuff in a Dictionary object?
Thanks for any help,
Nik
___
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/sandro.noel%40mac.com
This email sent to sandro.n...@mac.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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On 9 Jan 2009, at 15:53, Jens Bauer wrote: Hi Nik, self is a pointer, so you might want to change self. into self- No need to do that – assuming that label, pin and seed are declared as properties, which, this being a container class I guess they are. This also destroys the need to play with retaining that you were talking about (assuming the property is set up correctly to generate code that retains values). Bob ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On 9 Jan 2009, at 16:13, Andy Lee wrote: I haven't checked, but I suspect the compiler chooses the right thing, since this is only a warning. Maybe someone knows a way to disable the warning? In Java, I wouldn't be surprised if there were a way to enable a similar warning. The compiler will chose the name binding from the inner-most scope, so in this case, label will refer to the argument. In practice though, it's a bad idea to name the two the same – I tend to use initPropertyName in my init functions, and newPropertyName in my setters (if I'm using @dynamic). But then this is coming from the point of view of someone who uses -Wall -Werror. Bob___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Jan 9, 2009, at 9:13 AM, Andy Lee wrote: I haven't checked, but I suspect the compiler chooses the right thing, since this is only a warning. Maybe someone knows a way to disable the warning? In Java, I wouldn't be surprised if there were a way to enable a similar warning. --Andy Don't do that - compiler warning exist for reasons: to help prevent you from writing buggy code. In this case the warning isn't that the compiler is going to do the wrong thing (since it basically gets to define what is right and wrong - and it is right), it's that your code (or somebody else's code who has to later maintain this code) is potentially going to make a mistake and use label when they mean the instance variable, and not label the parameter (and then things will break). Compiler warning are basically its way of saying I'm going to do something that you told me to, but it may not be what you meant, since what you wrote could be ambiguous or have undefined results. Fix the warning, don't disable it. Glenn Andreas gandr...@gandreas.com http://www.gandreas.com/ wicked fun! JSXObjC | 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
You're right, it's not needed, and furthermore, I just checked, the warnings won't disappear. Everyone, disregard what I wrote about self- I believe that prefixing the parameters is most likely the best way (and as a good example for us, the guys at Apple does it as well). Love, Jens On Jan 9, 2009, at 16:09, Thomas Davie wrote: self is a pointer, so you might want to change self. into self- No need to do that – assuming that label, pin and seed are declared as properties, which, this being a container class I guess they are. This also destroys the need to play with retaining that you were talking about (assuming the property is set up correctly to generate code that retains values). ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Jan 9, 2009, at 10:20 AM, glenn andreas wrote: On Jan 9, 2009, at 9:13 AM, Andy Lee wrote: I haven't checked, but I suspect the compiler chooses the right thing, since this is only a warning. Maybe someone knows a way to disable the warning? In Java, I wouldn't be surprised if there were a way to enable a similar warning. --Andy Don't do that - compiler warning exist for reasons: to help prevent you from writing buggy code. In this case the warning isn't that the compiler is going to do the wrong thing (since it basically gets to define what is right and wrong - and it is right), it's that your code (or somebody else's code who has to later maintain this code) is potentially going to make a mistake and use label when they mean the instance variable, and not label the parameter (and then things will break). Compiler warning are basically its way of saying I'm going to do something that you told me to, but it may not be what you meant, since what you wrote could be ambiguous or have undefined results. Fix the warning, don't disable it. True. Even if a way does exist to disable it, you should really avoid it in the first place. --Andy ___ 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 arch...@mail-archive.com
[commentary] The value of warnings [was: Re: A Data Object in Cocoa]
From time to time I see questions arise and comments made about disabling warnings. I am reposting commentary made very recently since I believe it is a powerfully stated argument in favor of having the compiler generate warnings (-Wall, etc.), and for writing code that doesn't cause the compiler to emit them. [My apologies for being redundant, but thought this perspective might be missed by those not following the OPs thread on parameter naming.] On Jan 9, 2009, at 5:28 AM, glenn andreas wrote: On Jan 9, 2009, at 9:13 AM, Andy Lee wrote: I haven't checked, but I suspect the compiler chooses the right thing, since this is only a warning. Maybe someone knows a way to disable the warning? In Java, I wouldn't be surprised if there were a way to enable a similar warning. --Andy Don't do that - compiler warning exist for reasons: to help prevent you from writing buggy code. In this case the warning isn't that the compiler is going to do the wrong thing (since it basically gets to define what is right and wrong - and it is right), it's that your code (or somebody else's code who has to later maintain this code) is potentially going to make a mistake and use label when they mean the instance variable, and not label the parameter (and then things will break). Compiler warning are basically its way of saying I'm going to do something that you told me to, but it may not be what you meant, since what you wrote could be ambiguous or have undefined results. Fix the warning, don't disable it. My small addition: I consider that warnings are less about what one is doing in the very moment of composing code, but about interpreting code in the future, because when when writing code so much unstated context is alive in our head, but later all that (valuable) additional context is (often) gone, and the code must stand plainly on its own. ___ 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 arch...@mail-archive.com
Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]
On Jan 9, 2009, at 1:01 PM, Stuart Malin wrote: My small addition: I consider that warnings are less about what one is doing in the very moment of composing code, but about interpreting code in the future, because when when writing code so much unstated context is alive in our head, but later all that (valuable) additional context is (often) gone, and the code must stand plainly on its own. I believe comments and documentation are the best way to handle context (so it's not unstated :-) ), but I admit that not only have I not thought about this as an argument for -Wall et al, but I find I agree 100%. Well said. I'll add one of my own favorite statement: A computer is just like an under-socialized geek - it takes everything *way* too literally. Do you really want to trust that it gets it? -- 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Jan 9, 2009, at 1:49 AM, nik heger wrote:
- (id)initWithLabel:(NSString *)label pin:(NSString *)pin seed:
(NSString *)seed {
if (self = [super init]) {
self.label = label; ///--- compiler complains
self.pin = pin;
self.seed = seed;
}
return self;
}
I get three warnings that say local declaration of x overrides
instance variables. I thought I could differentiate between the
parameters and the instance variables using self.variable vs just
variable.
The ambiguity isn't on the left side of the assignment. That is clear
enough with the dot syntax. The problem is on the right side, where a
plain, unadorned label could be an attempt to reference the
parameter or the instance variable.
Dot syntax is one way of accessing your properties, but not the only
way. The lack of dot syntax doesn't make an identifier fail to match
an instance variable.
Regards,
Ken
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
I've noticed a pattern in some Apple code where the instance variables are
all prefixed with an underscore, but the property name, and therefore the
accessors, are what you'd expect. This leaves you free to use the same name
for arguments. To make the property point to the right variable, use an =
after the synthesize statement:
@interface MyObj
{
int _foo;
}
@property (readwrite, assign) int foo;
@end
@implementation MyObj
@synthesize foo = _foo;
- (id)initWithInt:(int)foo
{
if (![super init])
return nil;
[self setFoo:foo];
return self;
}
@end
Cheers,
Adam
On Fri, Jan 9, 2009 at 6:47 PM, Ken Thomases k...@codeweavers.com wrote:
On Jan 9, 2009, at 1:49 AM, nik heger wrote:
- (id)initWithLabel:(NSString *)label pin:(NSString *)pin seed:(NSString
*)seed {
if (self = [super init]) {
self.label = label; ///--- compiler complains
self.pin = pin;
self.seed = seed;
}
return self;
}
I get three warnings that say local declaration of x overrides instance
variables. I thought I could differentiate between the parameters and the
instance variables using self.variable vs just variable.
The ambiguity isn't on the left side of the assignment. That is clear
enough with the dot syntax. The problem is on the right side, where a
plain, unadorned label could be an attempt to reference the parameter or
the instance variable.
Dot syntax is one way of accessing your properties, but not the only way.
The lack of dot syntax doesn't make an identifier fail to match an instance
variable.
Regards,
Ken
___
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/acfoltzer%40gmail.com
This email sent to acfolt...@gmail.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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Fri, Jan 9, 2009 at 7:11 PM, Adam Foltzer acfolt...@gmail.com wrote:
- (id)initWithInt:(int)foo
{
if (![super init])
return nil;
[self setFoo:foo];
return self;
}
Do not use getters and setters in -init. You should be accessing the
ivars directly.
--Kyle Sluder
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
I stand corrected; I've seen this many times before, and have never had
problems. I'm guessing it's one of those patterns that causes problems under
specific circumstances?
Cheers,
Adam
On Fri, Jan 9, 2009 at 7:40 PM, Kyle Sluder kyle.slu...@gmail.com wrote:
On Fri, Jan 9, 2009 at 7:11 PM, Adam Foltzer acfolt...@gmail.com wrote:
- (id)initWithInt:(int)foo
{
if (![super init])
return nil;
[self setFoo:foo];
return self;
}
Do not use getters and setters in -init. You should be accessing the
ivars directly.
--Kyle Sluder
___
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Jan 9, 2009, at 8:28 PM, Adam Foltzer wrote:
I stand corrected; I've seen this many times before, and have never
had
problems. I'm guessing it's one of those patterns that causes
problems under
specific circumstances?
Yes, only under certain situations. I've been personally calling
accessors from both init and dealloc in shipping apps over the past 5
years. However, in my specific case, I'm the sole author so have
complete control over how the code is called.
I do have a todo in my eventual list of tasks to refactor the code.
On Fri, Jan 9, 2009 at 7:40 PM, Kyle Sluder kyle.slu...@gmail.com
wrote:
On Fri, Jan 9, 2009 at 7:11 PM, Adam Foltzer acfolt...@gmail.com
wrote:
- (id)initWithInt:(int)foo
{
if (![super init])
return nil;
[self setFoo:foo];
return self;
}
Do not use getters and setters in -init. You should be accessing the
ivars directly.
___
Ricky A. Sharp mailto:rsh...@instantinteractive.com
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 arch...@mail-archive.com
Re: A Data Object in Cocoa
Adam Foltzer (acfolt...@gmail.com) on 2009-01-09 9:28 PM said: I stand corrected; I've seen this many times before, and have never had problems. I'm guessing it's one of those patterns that causes problems under specific circumstances? See this thread: http://www.cocoabuilder.com/archive/message/cocoa/2008/10/8/219728 Basically, in init and dealloc, you should message ivars directly instead of using setters. Sean ___ 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 arch...@mail-archive.com
Re: A Data Object in Cocoa
On Jan 9, 2009, at 6:47 PM, Sean McBride wrote: See this thread: http://www.cocoabuilder.com/archive/message/cocoa/2008/10/8/219728 Basically, in init and dealloc, you should message ivars directly instead of using setters. http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_4.html mmalc ___ 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 arch...@mail-archive.com
