Re: Properties and memory management with overrides.

On Jan 26, 2009, at 2:45 PM, Sean McBride wrote: On 1/18/09 4:29 PM, Ben Trumbull said: I mention this because (I'm embarrassed to admit) I never really thought about this till yesterday. I *think* other design decisions have made the atomic-ness irrelevant to any of the code I've written,

Re: Properties and memory management with overrides.

On Jan 26, 2009, at 16:26, Bill Bumgarner wrote: However, even if only one thread can be changing the data, atomicity still matters. If the accessors aren't atomic, multiple read-only users of the data (in different threads) might get completely bogus results. This problem *can* be solved b

Re: Properties and memory management with overrides.

On Jan 26, 2009, at 4:00 PM, Quincey Morris wrote: Although the rationale for non-atomicity runs under the general thread-safety discussion umbrella, there are actually two separate issues to consider. It helps to explicitly *not* think about atomicity under the same umbrella as thread saf

Re: Properties and memory management with overrides.

On Jan 26, 2009, at 14:45, Sean McBride wrote: On 1/18/09 4:29 PM, Ben Trumbull said: I mention this because (I'm embarrassed to admit) I never really thought about this till yesterday. I *think* other design decisions have made the atomic-ness irrelevant to any of the code I've written, bu

Re: Properties and memory management with overrides.

On 1/18/09 4:29 PM, Ben Trumbull said: >> I mention this because (I'm embarrassed to admit) I never really >> thought about this till yesterday. I *think* other design decisions >> have made the atomic-ness irrelevant to any of the code I've written, >> but now I need to go back and check, especia

Re: Properties and memory management with overrides.

And (I assume, for the same reason) that since the property is by default atomic, the override is also responsible for implementing any actual atomic behavior. That's true. Custom accessor methods should respect the property attributes or the property attributes should reflect the behavior of

Re: Properties and memory management with overrides.

On Jan 18, 2009, at 13:52, Mike Abdullah wrote: You're overriding the method, so it is up to you to implement the copying behaviour. On 18 Jan 2009, at 21:19, Sandro Noel wrote: Greetings. This is probably a stupid question. if i have a property declared as @property (readwrite, copy) NSS

Re: Properties and memory management with overrides.

You're overriding the method, so it is up to you to implement the copying behaviour. On 18 Jan 2009, at 21:19, Sandro Noel wrote: Greetings. This is probably a stupid question. if i have a property declared as @property (readwrite, copy) NSString *name; if I override the -(void) setName(NS

Re: Properties and memory management

On Aug 5, 2008, at 15:28 , Uli Kusterer wrote: On 05.08.2008, at 22:24, Marcel Weiher wrote: On Aug 5, 2008, at 2:57 , Uli Kusterer wrote: Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY() macros for these purposes, and since most of my code still needs to be 10.4-compatible

Re: Properties and memory management

On 05.08.2008, at 22:24, Marcel Weiher wrote: On Aug 5, 2008, at 2:57 , Uli Kusterer wrote: You may fire off observer methods too, which is probably undesirable. Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY() macros for these purposes, and since most of my code still ne

Re: Properties and memory management

On Aug 5, 2008, at 2:57 , Uli Kusterer wrote: You may fire off observer methods too, which is probably undesirable. Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY() macros for these purposes, and since most of my code still needs to be 10.4-compatible, I've mostly been usin

Re: Properties and memory management – sorr y, not send to the list

Am Di,05.08.2008 um 11:57 schrieb Uli Kusterer: You may fire off observer methods too, which is probably undesirable. Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY() macros for these purposes, and since most of my code still needs to be 10.4-compatible, I've mostly been us

Re: Properties and memory management

Am Di,05.08.2008 um 12:05 schrieb mmalc crawford: On Aug 5, 2008, at 3:00 AM, mmalc crawford wrote: No, this is not the case -- Ken's reply was correct. If you use automatic KVO notifications, your accessors will still have side effects. Although I should add that of course by the ti

Re: Properties and memory management

Am Di,05.08.2008 um 12:00 schrieb mmalc crawford: On Aug 5, 2008, at 2:48 AM, Negm-Awad Amin wrote: This is the "mirror" of the problem, when you initialize an object. Of course, theoretically in both cases the usage of setters are dangerous. In most cases the deallocation of the object

Re: Properties and memory management

On Aug 5, 2008, at 3:00 AM, mmalc crawford wrote: No, this is not the case -- Ken's reply was correct. If you use automatic KVO notifications, your accessors will still have side effects. Although I should add that of course by the time you reach dealloc you should not have observers...

Re: Properties and memory management

On Aug 5, 2008, at 2:48 AM, Negm-Awad Amin wrote: This is the "mirror" of the problem, when you initialize an object. Of course, theoretically in both cases the usage of setters are dangerous. In most cases the deallocation of the object in reverse order to its initialization will not lea

Re: Properties and memory management

You may fire off observer methods too, which is probably undesirable. Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY() macros for these purposes, and since most of my code still needs to be 10.4-compatible, I've mostly been using those:

Re: Properties and memory management

Am Di,05.08.2008 um 11:02 schrieb Ken Ferry: On Tue, Aug 5, 2008 at 1:12 AM, Uli Kusterer <[EMAIL PROTECTED]> wrote: On 05.08.2008, at 05:55, Jonathan Hess wrote: The implementation of the property will manage the retaining and the releasing. You only need to worry about sending retain and r

Re: Properties and memory management

On Tue, Aug 5, 2008 at 1:12 AM, Uli Kusterer <[EMAIL PROTECTED]> wrote: > On 05.08.2008, at 05:55, Jonathan Hess wrote: >> >> The implementation of the property will manage the retaining and the >> releasing. You only need to worry about sending retain and release messages >> manually if you access

Re: Properties and memory management

Am Di,05.08.2008 um 10:12 schrieb Uli Kusterer: On 05.08.2008, at 05:55, Jonathan Hess wrote: The implementation of the property will manage the retaining and the releasing. You only need to worry about sending retain and release messages manually if you access the instance variable direc

Re: Properties and memory management

On 05.08.2008, at 05:55, Jonathan Hess wrote: The implementation of the property will manage the retaining and the releasing. You only need to worry about sending retain and release messages manually if you access the instance variable directly (not through a property). The only place you wo

[SOLVED[ Re: Properties and memory management

Thanks! For some reason I was finding it extremely hard to find the answer in the docs. Mike On Aug 4, 2008, at 8:55 PM, Jonathan Hess wrote: Hey Mike - The implementation of the property will manage the retaining and the releasing. You only need to worry about sending retain and release

Re: Properties and memory management

Hey Mike - The implementation of the property will manage the retaining and the releasing. You only need to worry about sending retain and release messages manually if you access the instance variable directly (not through a property). The only place you would typically need to do that wo