Re: Setter Gettor method style

[Nicola Pero]

> Hi there!
> 
> Sorry if I spring in here, but I'd like to ask you about a topic wich 
> was discussed in depth on the Apple Cocoa Mailing list lately:
> 
> The question was how getter setter methods are written and they came 
> to the conclusion that these are the way's:


> Now, what I'd like to ask you is what you think about it and what 
> style is used in the GnuStep frameworks?

Normally, gnustep uses

- (id) name
{
  return name;
}

- (void) setName: (id) aName
{
  ASSIGN (name, aName);
}

If you are using a garbage collector, memory related issues will be
managed for you automatically - if you are not, you need to know about
release/retain/autorelease stuff in all cases, and a simple consistent
efficient implementation in the library makes things easier.

In some cases, the caller needs not retain the returned value as there is
no chance that setName: might be called while the caller is holding a
pointer to name; in those cases, the retain/autorelease can be avoided;
and the retain/autorelease can be extremely expensive to do in certain
situations.

In other cases, the caller does need to retain the returned value as there
is a chance that setName: might be called while the caller is holding a
pointer to name.  (even in this case, if the caller does it, it can use a
'release' rather than an 'autorelease' when it's done with the object,
which might in some cases cause the object to be destroyed sooner, and the
program to eat up less memory)

The caller can/has to choose what to do in each situation.  I don't see
this as a drawback, but as an advantage.

If the library implements the setter/getter in the simplest way, you can
always control the behaviour you want (fast vs retain/autorelease vs
retain/later release vs ...) from the caller.  If the library always does
a [[[myObject name] retain] autorelease] instead, the caller has no
control, and always gets a terribly slow implementation.  Which makes the
library definitely less flexibile, because in some cases, you do need to
manage thousands of objects in loops very quickly, and you do need raw
speed, so you need to be able to control that a release/autorelease which
you know it's useless is not automatically performed by the library.


Of course, this does not hold true in all cases.  There are cases in which
the library does (and should do!) differently - these cases should be
documented.