Re: A Data Object in Cocoa

On Sun, Jan 11, 2009 at 10:08 AM, glenn andreas 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

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, b

Re: A Data Object in Cocoa

On Sat, Jan 10, 2009 at 3:33 PM, Andy Lee wrote: > On Saturday, January 10, 2009, at 12:39PM, "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.

Re: A Data Object in Cocoa

On Sat, Jan 10, 2009 at 2:40 PM, jonat...@mugginsoft.com wrote: > > On 10 Jan 2009, at 19:23, Michael Ash wrote: >> 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

Re: A Data Object in Cocoa

On 10 Jan, 2009, at 3:28 AM, 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? To give some concrete examples where calling a setter from -init or

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 wa

Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]

On Sat, Jan 10, 2009 at 6:20 PM, Sean McBride 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*)wi

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 r

Re: A Data Object in Cocoa

On Saturday, January 10, 2009, at 12:39PM, "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..

Re: A Data Object in Cocoa

On Saturday, January 10, 2009, at 12:18PM, "Michael Ash" wrote: >Mechanisms like KVC will >look for ivars both with and without the underscore. Yup: file://localhost/Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/C

Re: A Data Object in Cocoa

On 10 Jan 2009, at 19:23, Michael Ash wrote: On Sat, Jan 10, 2009 at 12:39 PM, 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 wrote: On 10 Jan 2009, at 16:48, Michael Ash wrote: As for underscore being res

Re: A Data Object in Cocoa

On Sat, Jan 10, 2009 at 12:39 PM, 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 >> wrote: >>> >>> On 10 Jan 2009, at 16:48, Michael Ash wrote: >>> As for underscore being reserved, I have never been ab

Re: A Data Object in Cocoa

On 10 Jan 2009, at 17:18, Michael Ash wrote: On Sat, Jan 10, 2009 at 12:08 PM, Alastair Houghton 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 y

Re: A Data Object in Cocoa

On Sat, Jan 10, 2009 at 12:08 PM, Alastair Houghton 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

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

Re: A Data Object in Cocoa

On Sat, Jan 10, 2009 at 7: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

Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]

On Sat, Jan 10, 2009 at 12:56 AM, Andrew Farmer 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,

Re: A Data Object in Cocoa

On 10 Jan 2009, at 13:00, Ricky Sharp wrote: On Jan 10, 2009, at 6:45 AM, Alastair Houghton wrote: 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 i

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. Exce

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 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.

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 us

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 develo

Re: [commentary] The value of warnings [was: Re: A Data Object in Cocoa]

On 09 Jan 09, at 15:41, I. Savant wrote: 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 unsta

Re: A Data Object in Cocoa

On Jan 9, 2009, at 6:47 PM, Sean McBride wrote: See this thread: Basically, in init and dealloc, you should message ivars directly instead of using setters.

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:

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

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 wrote: > On Fri, Jan 9, 2009 at 7:11 PM, Adam Foltzer wrote: > >

Re: A Data Object in Cocoa

On Fri, Jan 9, 2009 at 7:11 PM, Adam Foltzer 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

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 =

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 = s

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 lat

[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 co

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 w

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

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

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

Re: A Data Object in Cocoa

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 On Jan 9, 2009, at 9:59 AM, Sandro Noel wrote:

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

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 whateve

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) { l