Re: Setter Gettor method style

[Alexander Malmberg]

> The rules I got along with the Foundation in NeXTSTEP 3.3 were:
> 
>     - initXxxx return retained objects, (POST: [result retainCount]==1)

Or nil and the original object has been deallocated.

>     - classXxxx (stringWithFormat:, etc) return autoreleased objects,
> 
>     - accessors, since they return attributes don't return
>       autoreleased objects, but retained objects
>       (POST: [result retainCount]>=1).

I'd add:

- non-accessors (like [NSString -lowercaseString]) return autoreleased
objects unless the name is clearly marked (eg. getFoo: (id *)f or
[NSCell -_nonAutoreleasedTypingAttributes]).

This is acceptable for performance, and it seems most of the existing
code works this way, but it leads to objects with very uncertain
lifetimes, especially wrt threads, instead of the clear 'it's in the
current autoreleasepool'.

[snip]
> There's  no reason to  retain the  title.  That  is, one  expects, and
> should check, that the preconditions/postconditions of setColor: don't
> have any side-effect on the title object returned before.

But this means that you'd have to check for not-necessarily-obvious
side-effects for just about every method when you're using accessors.
The semantics of accessors would be very non-obvious. If you retain
everything just to be safe, the accessors might as well retain it for
you.

[snip]
> But  as always,  my  main point  is  that this  should be  explicitely
> documented.   The use  of return([[attribute  retain]autorelease]); is
> not failproof (foolproof?!);
> 
>       NSAutoreleasePool* pool=[[NSAutoreleasePool alloc]init];
>       NSString* title=[stuff title];
>       [stuff setTitle:@"New title"];
>       [pool release];
>       NSLog(@"old title was %@\n",title); // title is deleted...
> 
[snip long example]

There is no problem here. The accessor returns an autoreleased object.
If you want to bring the object out from an autoreleasepool, you'll have
to retain it and autorelease it again in the next autoreleasepool, just
as you'd have to do with any other autoreleased object.

> The  rule that  says that  you  must retain  the objects  you need  is
> failproof in all cases.

No. Obscure cases involving multiple threads could be constructed where
{[foo retain] autorelease] worked properly but retaining it after it's
been returned doesn't.

> --
> __Pascal_Bourguignon__                   http://www.informatimago.com/
> ----------------------------------------------------------------------

- Alexander Malmberg