Re: Memory Management (Part II)
Re: Memory Management (Part II)
- Subject: Re: Memory Management (Part II)
- From: Nat! <email@hidden>
- Date: Fri, 1 Aug 2003 00:55:55 +0200
If I code something like this:
- (NSString *) name
{
return( [name_ retain]);
}
I am sharing ownership with the caller.
Sorry, I don't see this at all. You are retaining the object. So you
have just said that you want to own the object even more, which makes
no sense.
OK this is an argument :) It gets a little clearer though if you
consider name_ to be a NSMutableString and you are saying copy instead
of retain. You're giving a copy back. I used retain, because of the
mail thread here but copy is probably easier to understand.
The Foundation way to achieve almost fail safeness is to provide the
caller with [... retain] autorelease] a return value, which gives
full read access during the scope of the callers(!) autorelease pool.
Once again, not really. Autorelease is provided for the cases where
you actually could not return the value at all without doing the
retain (in callee) release (in caller) dance routine because the
object would get deallocated in the meantime.
This probably hinges on either my or your misconception with the
autorelease pool and object lifetime. Lets resolve that first :)
The reason why you get these funny problems when name_ is mutable is,
because you are not yielding access completely, the contents are
still subject to change by the messaged instance. That's why using
copy] autorelease] would be proper, as it also gives the full access
rights of the return value contents to the caller (within the
scope... bla bla).
Once again, being mutable and sharing is inherent in an imperative
programming language. The fact that you are saying one should be
copying values is a strong indication that you are after referential
transparency. I can just repeat that you aren't going to get it in
Objective-C ever, and you waste a lot of cycles not getting it... ;-)
Again I am not after anything. My previous mail just said (in a little
more detail :)
a) passing in the return value to be filled, gives the caller total
fail safety (or total control of the return value whatever you like
better). We don't do it because it's too much hassle.
b) returning a copy (or a retained value of an immutable object) is
also fail safe. We don't do it because it's too much hassle.
c) getting a copied/retained/autoreleased value back, gives the caller
the guarantee that the object lives until the callers autorelease pool
dies. This is convenient but a little slow.
d) getting a shared value back, forces the caller to start thinking
about what he is doing more. This is fast but more dangerous than c.
I am not promoting the use of retain] autorelease] (I dislike
slowness :)), but I don't mind it to be the documentation default.
I do.
1) It creates more problems than it solves (masking/delaying erros
until the autorelease pool pops)
A theory, if this is quantitatively really the case, would be a huge
study.
2) The problem it 'solves' is exceedingly rare in practice
Can't say that. Actually bites me every few months or so. Shared
editing cell in Cocoa f.e.
3) It actually doesn't even 'solve' that, because important cases are
exceptions (collections, 'performance critical' code)
If that keeps noobs from littering their code with @try @catch, it's
probably a good thing :)
4) The real solution in those exceedingly rare cases that need it is
trivial: let the caller retain
But how will you know, when a case is exceedingly rare ?
5) Having the retain in the calling code makes it intention revealing,
showing what you actually wanted to do at that point
yeah, well but you get lazy. I mean
s = [[NSString alloc] initWithString:@"foo"];
t = [s description]; // s could've just returned self.
must I really retain t, to be intention revealing ?
6) Due to (4) it complicates the rules instead of simplifying them
7) It also complicates object lifetimes / the object ownership rules
I'd oppose that it actually simplifies them.
8) It creates expectations of "safety" that an imperative language can
never fulfill
I rather think it creates expectations of "safety" that Foundation or
Cocoa will practically never fulfill :)
9) The cases where it applies are cases where you need to think about
your sharing semantics anyhow (see 5)
I do not think so see 5)
10) The performance cost (factor 10) is quite significant, and
non-localized
Yeah, I don't like it either.
Ciao
Nat!
(*) for adv.diabol. The retain/release mechanism is externalized and is
not referenced by that memory ? Wrong it is indexed by that memory.
That counts as well.
------------------------------------------------------
People are quite at home with evil. ... It's fighting
it that raises the dreadful specter of inconvenience.
-- McEldowney
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.