Re: Setter Gettor method style

[Pascal Bourguignon]

> From: Alexander Malmberg <alexander@malmberg.org>
> Date: Sun, 04 Aug 2002 22:41:27 +0200
> 
> [snip]
> > I find it difficult to choose one way or another.
> 
> I agree. 'return foo;' is faster and easier to write. Thread safety is
> probably the main issue.
> 
> >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.
 

> > >From the point of view of the caller,
> > 
> >        NSString* title=[stuff title];
> >        NSLog(@"title= %@\n",title);
> >        [stuff setTitle:@"New title"];
> >        NSLog(@"title= %@\n",title);
> > 
> > without further information you could as well expect to get as output:
> > 
> >         title= Old title
> >         title= New title
> 
> I'd expect the call to -title to return the value at the time it is
> called, autoreleased and in such a way that it stays the same. This does
> depend on how you define things, but for something like -setTitle: and
> -title, I'd expect the value to be the primary thing, not the objects.

We agree,  title should be an attribute.  Current implementation makes
it half an attribute, half a relationship...
 
> [snip]
> > Therefore,  we  are  either:
> > 
> >    - in a  case where  we have attributes,  encapsulated in  the owner
> >      object, and in this case we  keep a copy in the settor and return
> >      a copy in the gettor,
> 
> And the copy is autoreleased.

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,
is that it fulfill encapsulation and allow a change of implementation.
You  could instead  have a  {char _attribute[MAXLEN];},  and  return a
[NSString stringWithCString:_attribute], or  fetch the attribute value
from  some  subobjects  (NSWindow  could  fetch  the  title  from  the
miniwindow titleCell for example).

> >  - (id) contentView
> >     Returns the NSWindow's content view.
> > 
> >  - (void) setContentView: (NSView *) aView
> >     Makes  aView  the NSWindow's content view.
> 
> Yes. In this case we're interested in the object.
> 
> [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.
 
> - Alexander Malmberg

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