Re: Memory Management
Re: Memory Management
- Subject: Re: Memory Management
- From: Philippe Mougin <email@hidden>
- Date: Thu, 31 Jul 2003 14:21:46 +0200
IMO, the main goal of the retain] autorelease] form in the accessors is
very respectable: ensuring that an object you just received will not be
freed as a side effect of another method you may call. Of course, there
is already an existing solution to this: when this may happen, you
(i.e., the caller) retain the object you want to keep around during the
execution of your method. But I think the idea of generalizing the new
solution solution (i.e., invoking retain and autorelease on objects
before returning them) and making it the default coding convention is
to make things simpler for programmers. With such a new convention,
which states that the retain] autorelease] is the default technique,
you can assume that the object you just received will stay around
during the execution of your method. No more need to bother ensuring
manually that the object will stay around: simpler conceptual model,
simpler programming model, more robust code.
The problem is that, overall, it does not work. First, it fails to
makes things simpler: it introduces a new convention that programmers
have to follow when coding a method that return an object. Upfront, it
introduces exceptions to this convention. Furthermore, it states that
if some methods do not conform to the convention, this should be well
documented. But we know that there is already a large corpus of
Objective-C libraries that have been produced before the introduction
of this convention and which, obviously, do not document this fact.
Actually, with this convention, things becomes more complex for
everyone: overall, the conceptual model becomes more complex (because
we now need to master both the conceptual model promoted by the new
convention and the old conceptual model applying to the exceptions),
the documentation becomes more complex, errors will be harder to track,
in doubt the caller will have to retain anyway, if it does assume that
the convention is followed whereas this is not the case this will
introduce errors etc.
In addition, this technique cripples performances. One of the things
that can kill overnight an object-oriented framework and run-time like
Cocoa is people realizing that applications developed with the
technology are too slow. Generalizing a technique that slow down things
as common as accessors by an order of magnitude or more should only be
done for VERY, VERY good reasons. In the case at hand, I don't think it
is worth it.
Introducing important coding and documentation conventions like this,
is something that should only be done in last resort, when all the
other solutions are clearly worse. In our case, the problem at hand is,
in practice, quite uncommon, and there is already a BETTER solution
(simpler, not relying on a coding convention, safer, and that still
allows you to use retain] autorelease] in your accessors if you want to
provide some extra robustness in case of buggy callers). The memory
management model is already sufficiently complex, error prone and
limited (all due to the intrinsic problems of reference counting in a C
based language and to the fact that dynamic resource management is not
a simple problem). Let us retain (ha ha) from making it more complex,
brittle and slower.
Phil
_______________________________________________
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.