Re: Setter Gettor method style

[Pascal Bourguignon]

> From: Alexander Malmberg <alexander@malmberg.org>
> Date: Sun, 04 Aug 2002 19:25:24 +0200
>
> > 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]).

Agree.

> 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.


I find it difficult to choose one way or another.

The point is that we're speaking of attributes:

    +---------------------------------+
    |           SampleClass           |
    +---------------------------------+
    | attribute:string;               |
    |                                 |
    +---------------------------------+
    | setAttribute(newValue:string);  |
    | getAttribute() return string;   |
    |                                 |
    +---------------------------------+
                        Diagram 1.

that are actually implemented with another object and a relation:

    +-----------------------------------+             attribute +----------+
    |           SampleClass             |-----------------------| NSString |
    +-----------------------------------+ 0,*                 1 +----------+
    |                                   |                            |
    +-----------------------------------+                           /_\
    | setAttribute(newValue:NSString*); |                            |
    | getAttribute() return NSString*;  |                 +-----------------+
    +-----------------------------------+                 | NSMutableString |
                                                          +-----------------+
                        Diagram 2.


I feel that the right solution is to take copies and return copies:

  -(void)setAttribute:(NSString*)newValue
  {
     [_attribute release];
     _attribute=[[newValue copy/*or mutableCopy if it can be edite by self*/]
                      retain];
  }//setAttribute:;

  -(NSString*)getAttribute
  {
    return([_attribute copy]);
  }//getAttribute;

Well, since getAttribute returns a copy for the exclusive usage of the
caller, it could as well return a mutableCopy to allow the called edit
the result without having to do a new mutable copy itself.

What is the difference in performance of copy and mutableCopy?


Now, the problem comes when one realise that most ofthen setAttribute:
is passed an newly allocated / constructed autoreleased NSString, that
would not be further owned and used by the called.

Then, as  an optimisation,  we want to  use directly this  object, and
instead  of a  mere "attribute",  incorporated to  the object,  we are
actually establishing a relation with a NSString object.

  -(void)setAttribute:(NSString*)newObject
  {
     [_attribute release];
     _attribute=[newObject retain];
  }//setAttribute:;

With the  problem that if newObject  is a mutable object,  it could be
edited by the caller without  self object noticing.  Which would be ok
if attribute were really a  distinct object in relation with self, and
not an internal attribute.

So, if you are in the case  of Diagram 1 and want to have attribute, I
would say that you  must copy values. And only if you  are in the case
of  Diagram 2  and  have  relationship with  NSString  and other  data
objects you  may keep a pointer to  the same object and  then you must
expect it to be edited by the rest of the program.


Now, about the gettor.

If  you consider you  have an  attribute (Diagram  1) then  you should
return  a copy  object,  and perhaps,  as  a favor  to  the caller,  a
mutableCopy.

Returning  a  pointer  to  one  of  your  attribute  is  a  breach  of
encapsulation. 


If you consider  you have a relationship with  a value object (Diagram
2),  then  of  course you  return  the  object  with which  you're  in
relationship with:


  -(NSString*)getAttribute
  {
     return(_attribute);
  }

and there  is no reason  to do anything  further.  Of course,  in that
case, you must accept that the returned object may be edited (it could
be a mutable object after all).




>From the point of view of the caller, 

       NSString* title=[stuff title];
       [stuff setTitle:@"New title"];
       SLog(@"old title was %@\n",title);

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