Re: Setter Gettor method style

[Alexander Malmberg]

> > >From the linked discussion, it seems that mosx is moving towards 'return
> > [[foo retain] release];', so compatibility might resolve this issue for
> > us :).
> 
> Beware, you mean: [[foo retain]autorelease]; don't you.

Yes. Sorry.

[snip]
> Right,  copy and mutableCopy return retained objects...
> 
> The point to have a "copy" mindset in the gettor of attributes instead
> of assuming [[_attribute retain]autorelease],  that is, not to let the
> client code assume it'll get a pointer to the actual attribute object,

True, but the caller shouldn't assume that it isn't a pointer to the
actual attribute, either.

[snip]
> > > In those cases, a return([_contentView retain]autorelease]); would be
> > > useful, and the GNUstep Documentation could say:
> >
> > Actually, in this case I don't think that it should do that (always the
> > opposite :). Then again, contentView is kindof tricky. But eg. NSArray
> > shouldn't mess with the objects it contains. It merely contains the
> > objects for the user. If the user wants to access it from several
> > threads, the user's responsible for locking around calls and
> > retaining/releasing properly.
> 
> Not  to  be confused  by  the  name  "contentView", or  the  graphical
> position  ("inside"  the  window),  there's  actually  a  relationship
> between NSWindow and  NSView to have a contentView.   Some other views
> don't have  this relationship and  are only "subviews" of  some other,
> possibly "contentView" views.

The subview stuff is actually more obvious, but in both cases, I'd say
that the NSWindow/NSView 'contains' the other NSView:s in a similar
sense to how an NSArray contains objects. Thus, they should be returned
as is (not retain/autoreleased).

- Alexander Malmberg