Re: Memory Management (Part I)
Re: Memory Management (Part I)
- Subject: Re: Memory Management (Part I)
- From: Nat! <email@hidden>
- Date: Fri, 8 Aug 2003 01:44:33 +0200
Am Mittwoch, 06.08.03 um 11:55 Uhr schrieb Marcel Weiher:
I ain't asking for nothing here :), I am pretty much completely
happy with Objective-C as it is, because I can achieve what you
call "referential transparency" _if_ _I_ _want_ _to_.
Once again, that is the big misconception. You cannot get
referential transparency. Objective-C has side-effects. End of
story,
wrong:
@interface Foo
...
NSMutableString *name_;
- (id) noSideEffect
{
return( [name_ copy]); // achieved it.
}
Ach, that isn't even wrong! Referential transparency is a global
property. Now think about your isolated example again.
Anyway, you can't be at all sure that even this isolated examples
achieves what you are thinking it does.
In your lofty kind of thinking you can't even be sure what [xxx retain]
does. retain could be calling release for that matter. Problem is,
nobody cares about this (except you). We are dealing with Cocoa here
and not with Obj-C abstract.
The problem is that you have apparently very little desire to
understand what I write. In my mail I was exactly NOT interested in
shared mutable values (*) .
That may be, but then you are missing the point. The problem is
*caused* by shared mutable values, and the fact that this is what an
imperative programming language like Objective-C is largely based on.
Well that's one big problem. That is not the problem retain]
autorelease] is gonna fix. Maybe your problem is, that you don't see
that there are two problems. You want the "big fix" that fixes both, I
am just considering the fix to the other (see below)..
If you restrict yourself to the subset of (Objective-)C that only
deals with values ( integers, floats, the like), then you will have
referential transparency. Alas, it won't be a very good language to
program in...
Actually I think you are starting to see the light :) Consider all
these non-mutable Foundation objects like NSNumber NSString, NSData as
"values". Now with the retain] autorelease] you alleviate one _other_
problem, the "sudden freeing" of that value as maybe(!) in
s = [[NSString alloc] initWithCString:"bla"];
t = [s description]; // might return self
[s release];
NSLog( @"accessing t may or may not crash : %@", t);
as the caller can now expect, that the value 't' will live on until his
autorelease pool expires. That's all I am talking about not more.
This is not a coincidence. Maybe sometimes it does help to think this
through in terms of memory and not in objects.
No.
Well we differ :)
Well looking from the caller (and that is the way I am looking at
it in this discussion)
You are looking at it procedurally...
The autorelease pool is in the callers domain, therefore this needs
to be "looked at procedurally" as you seem to be fond of calling it.
That is circular argument.
I'd say the argumentation is going in circles, not the argument. Don't
see that sorry.
Not any more than your discussion. The release can happen just as
easily indirectly, for example by the callee setting an instance
variable of another object, where the argument it received was the
previous value fo that instance variable. It is aliasing, you
cannot get around that.
I have looked in my previous mails, but don't see what code bit you
are referring here to, as in reference to the NSMutableString bit
(first case) it doesn't make sense to me.
Anyway are you trying to make an argument for autorelease here ? :)
No. It is a reductio-ad-absurdum. In order for the logic for
retain] autorelease] to be valid, you actually have to bracket *calls*
to methods with these constructs as well.
Because I didn't get the original idea, I have no clue how to parse
your meta argument. How about a little code snippet to show what you
mean.
Ciao
Nat!
------------------------------------------------------
Ich selbst habe mich persvnlich stets an den
sittlichen Gepflogenheiten des Philisters beteiligt;
nicht, weil ich ihnen Wert beigemessen hdtte, sondern
weil ich - vorwdrts, immer mal wieder! - keinen Anla_
traf, mich von ihnen zu trennen. -- H. Mann
_______________________________________________
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.