Since nobody was able to provide real answers to my questions, I wrote some
dummy code to find out as much about that issue as possible. Here are the
results:
Remember, I listed the following cases:
> a) retain
> b) retain, nonatomic
> c) copy
> d) copy, nonatomic
On 2011-06-29, at 21:50 , Quincey Morris wrote:
> You're looking for provable correctness. That's laudable, and will probably
> mean that you keep all of your fingers. But you'll still end up in the
> emergency room -- in your case it will be for a stress-induced ulcer. :)
My university profes
On Jun 29, 2011, at 12:08, Markus Hanauska wrote:
> I personally think a getter should always [snip] ...
You know, in the Cocoa world, we play with live ammo. When we are handed a
pointer without ownership, we go ahead and use it for a while without taking
ownership. For as long as we do that,
On 2011-06-29, at 20:08 , Matt Neuburg wrote:
> On Jun 29, 2011, at 10:39 AM, Markus Hanauska wrote:
>
>> If that was allowed, one would have to write code like this:
>>
>> id value = [someObject value];
>> [value retain];
>> [someOtherObject setValue:value];
>> [value relea
On Wed, Jun 29, 2011 at 10:39 AM, Markus Hanauska wrote:
> Yes, it talks about certain*exceptions*, and you are right, one of them is in
> fact destroying the parent, so I'm wiling to accept that you must not rely
> upon an object to stay alive longer than its parent. However, have you also
>
Still learning Cocoa myself, so hoping to be corrected if I'm wrong.
On Jun 29, 2011, at 10:39 AM, Markus Hanauska wrote:
> "Cocoa’s ownership policy specifies that received objects should typically
> remain valid throughout the scope of the calling method. It should also be
> possible to retur
On 2011-06-29, at 19:17 , Kyle Sluder wrote:
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html%23//apple_ref/doc/uid/TP40004447-1000922-BABBFBGJ
Yes, it talks about certain*exceptions*, and you are right, one of them is in
fact destro
On 2011-06-29, at 18:09 , Matt Neuburg wrote:
> As I said then, "Ownership is *never* something you are magically given.
Actually I have to correct my previous statement, since it is incorrect. I said:
Following your reasoning, Apple has to re-design Cocoa and re-write all guides
and sample co
On Wed, Jun 29, 2011 at 10:08 AM, Markus Hanauska wrote:
> Since when do you have to be owner of an object to be allowed to interact
> with it?
You're holding on to the result of -value. Therefore you need an
ownership reference to it.
This is something Cocoa programmers have needed to worry ab
On 2011-06-29, at 18:09 , Matt Neuburg wrote:
> As I said then, "Ownership is *never* something you are magically given.
Since when do you have to be owner of an object to be allowed to interact with
it?
This contradicts pretty much everything Apple has ever documented about
Cocoa/Obj-C.
Fol
On Wed, 29 Jun 2011 12:53:26 +0200, Markus Hanauska said:
>E.g. consider the following code:
>
> ObjectCreator oc = [[ObjectCreator alloc] init];
> id value = [oc value];
> [oc release];
> [value someMethod];
>
We actually had something very like this discussion here alrea
On 2011-06-29, at 13:58 , Fritz Anderson wrote:
> Apple may be (and probably is) using methods more primitive than
> retain/release/autorelease. It may (probably has, and very probably will)
> change the implementation between point releases of the operating system.
This is absolutely obviou
On 29 Jun 2011, at 5:53 AM, Markus Hanauska wrote:
> The code above already reveals a huge problem: When I read the terms "atomic"
> and "nonatomic", I certainly expect one to use a lock (or at least atomic
> operations of some kind) and the other one not. This is no big surprise. What
> is a b
Unfortunately the documentation on properties is really inadequate since Apple
fails to provide "pseudo-code" for every possible attribute combination. E.g.
the nonatomic attribute has a couple of dangerous side effects that seem to be
unknown even to developers using properties for years. The d
14 matches
Mail list logo
