Re: Memory Management (Part I)
Re: Memory Management (Part I)
- Subject: Re: Memory Management (Part I)
- From: Marcel Weiher <email@hidden>
- Date: Wed, 6 Aug 2003 10:55:39 +0100
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.
That's an implementation detail. The problem is not the memory, it
is the aliasing. If we have two references to things that are not
memory (two file handles, for example) the same thing happens.
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.
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...
Yes you were. I was saying that you are focusing on the call stack,
which is not appropriate in an OO environment.
There is nothing magical about the OO environment, sorry to inform you.
Nothing magical, correct. However, the entities that 'share' in an OO
environments are not just methods and their stack, but also objects,
which have decidedly non-stack lifetimes.
The memory area was provided for the method as a return value. If
the method chooses to retain it, it's breaking the contract. It's
equally breaking the contract if it does memset( s, 0, 16) on it.
Precisely! Relying on others to not do something they *can* do is
not fail-safe. It is fail-safe if it does not fail no matter what
others do.
If someone manages to mess this up, it's faulty class design.
Glad you finally see this. If you need to resort to autorelease to
resolve a *sharing* issue, then it is faulty class design.
If you provide a method with an object/memory to be used as a return
value, the method can not be assured of its contents after the call
has finished, because now the caller can change the values at will, so
there is no use in retaining it.
Changing the value has nothing to do with retaining.
This is not a coincidence. Maybe sometimes it does help to think this
through in terms of memory and not in objects.
No.
[..]
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...
In the first case, you also transfered a pointer to memory, from
the caller to the callee. This is just as unsafe because the
callee could have released the memory. There is no difference!
Yeah could have, but that's "make pretend".
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.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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.