Re: Memory Management (Part I)
Re: Memory Management (Part I)
- Subject: Re: Memory Management (Part I)
- From: Nat! <email@hidden>
- Date: Tue, 5 Aug 2003 02:36:27 +0200
- Resent-date: Wed, 6 Aug 2003 00:26:51 +0200
- Resent-from: Nat! <email@hidden>
- Resent-message-id: <D9C6CDCB-C6DC-11D7-A82C-003065A29EFC@mulle-kyberneti k.com>
- Resent-to: email@hidden
[too big again, so I edited more stuff out. hope it makes it this time]
disappointed, when it fails. Read the sentence in context with the
previous discusssion, it will make >> sense.
You obviously didn't understand what Marco was saying.
Convincing argument. I let the reader decide though :)
collection is created that has the element inserted at the right
spot. The old collection is not modified. Nothing is ever >>> modified.
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.
}
But in many cases I am very happy that the language doesn't force me
to do that. That's why you and me aren't coding Java (except for
money) :)
Java doesn't have referential transparency either, not by a long shot.
humour ? shouldn't have tried it...
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 (*) . I'd suggest rereading my mail from 29.July
2003 . If you have two references to things that are not memory or even
that are memory and two parties are content and interested in mutating
them, then PRECISELY you are not "yielding access completely", which as
I wrote is indeed problematic.
My mail was NOT at all about solving that problem. I can't help it that
your big fascination is with cases such as in f.e.
- (NSTask *) getATask
{
return( myTask_);
}
or
- (id) objectAtIndex:(unsigned int) index
{
return( array_[ index]);
}
(We'd probably both would not want to see retain/autorelease used in
those.)
But it wasn't my topic, and you missed the mark with your comments.
I am afraid you don't follow my argument here.
Quite the opposite, it appears...
I was at that paragraph exactly just talking about the caller
providing the memory,
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.
not the other way round (that's for later). Calling it object instead
of memory doesn't make it any different, more complex maybe,
No, it focuses on the concept instead of implementation details that
obscure what is actually happening.
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. 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.
This is not a coincidence. Maybe sometimes it does help to think this
through in terms of memory and not in objects.
But OK, another challenge, show some code where
- (void) getName:(NSMutableString *) s
{
[s setString:name_];
}
usefully retains 's' for later use, and code like this
s = [NSMutableString string];
[p getName:s];
[s appendString:@"-xxx"]; // or some other random mutation
doesn't destroy its usefulness for 'p'.
If the memory is solely owned by the method (instance), this means
a weakening in the fail-safeness
I don't agree with this. It is sharing, just like your other case,
except that it is the *object* doing the sharing, not the method.
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.
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 ? :)
Ciao
Nat!
(*)
yes, except for use as return value space of course...
------------------------------------------------------
Certainly there is no hunting like the hunting of man,
and those who have hunted armed men long enough and
like it, never really care for anything else
thereafter. -- Hemingway
_______________________________________________
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.