Re: Newbie: Proper objc style
Re: Newbie: Proper objc style
- Subject: Re: Newbie: Proper objc style
- From: "David W. Halliday" <email@hidden>
- Date: Mon, 10 May 2004 16:11:21 -0500
- Organization: TNRCC
mmalcolm crawford wrote:
On May 10, 2004, at 12:51 AM, Ondra Cada wrote:
On 10.5.2004, at 7:31, mmalcolm crawford wrote:
...
it is the responsibility of the method caller to retain them if
they want
which effectively means the returned object can be either
autoreleased, OR shared (a singleton), OR whatever (e.g., if it
makes sense in a particular case, the vendor may keep track of
vended objects and release them when some special conditions are met).
The only invariant is that the receiving code is not assumed to
release the object (unless it retained it).
...
The means of achieving that can differ and are not fixed anyhow;
vending an autoreleased object is just the most common one, but by
far not the only one.
Indeed.
...
mmalc
If I may step in here (hopefully without inserting foot in mouth)...
This is particularly addressed to Jorge Martins, but is especially
relevant here, I believe.
The most important part about naming the "objects{For,With}...", in
my opinion, is to help the user of this method know what it
does/returns. Adhering to a naming convention most definitely helps in
this regard.
The least important part---and I would even go so far as to say that
this should be avoided, if at all possible---is to tell the user of the
method how this method is implemented. I don't say this due to anything
having to do with reverse engineering or avoiding having someone ripping
off your code! It's really about encapsulation and (code) interface
design. Basically, you should provide the (code) interface in such a
way that you, as the implementor, have maximum freedom in how the
method/object/etc. is implemented. After all, you may find, at some
later time, that you have a far better way to implement the whole thing,
and you should be free to do so, without breaking the (code) interface.
So, if you are going to return an array of things, and you are not
guaranteeing that the array will exist beyond the present context, then
use the convention for such. This is permitted, even if you, as an
implementation detail, decide to cache the created array to be returned
in subsequent calls. At no time, for such a call, is the user to expect
that there is no penalty in reissuing the call: Any such assumption is
/not/ a part of the (code) interface contract---the user is simply being
told that you can provide the array, at will, and that the array is not
guaranteed to exist, outside the present context, unless the user
retains it.
In fact, even for an accessor method, which are often /assumed/ to
be used to access an instance variable (of like name and/or type), there
is no guarantee that there exists an kind of instance variable that's
associated with that accessor. Any such association is simply an
implementation detail. (You get the picture?)
Anyway, I hope I've helped, and not muddied the waters too much.
David
_______________________________________________
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.