Re: Accessors
Re: Accessors
- Subject: Re: Accessors
- From: Shawn Erickson <email@hidden>
- Date: Wed, 7 Aug 2002 09:21:40 -0700
On Wednesday, August 7, 2002, at 03:00 AM, Marcel Weiher wrote:
On Wednesday, August 7, 2002, at 11:29 Uhr, Chris Ridd wrote:
If the future change removes that instance variable, but you rewrite
the
"accessor" to synthesize a return value, what is the "accessor"
called then?
This surely breaks your simple classification scheme.
Not at all. In that case, it ceases to be an accessor. After all,
the point of accessors is that they are *methods*, in order to *hide*
wether they are just accessing an instance variable.
I am glad you brought this up: for a client, wether something is an
accessor or not does not and should not matter. For a client, it is
just a method that returns a value. Furthermore, a client shouldn't
have to distinguish between "simple collections" and "complex objects"
or whatever else in order to know what to do.
Just follow the ownership rules and you'll be fine.
So if I write my class to utilize an "accessor" on a third party
provided class (for example in a framework that is installed by others
on a users system).
Third Party Class...
SomeObject* someObject {
return someObject; //using the simple accessor scheme
}
My Class...
SomeObject so = [[[thirdParty someObject] retain] autorelease];
//need to do the retain autorelease thing because of the simple
accessor scheme
[so doSomething];
....
Then the third party changes things such that the "someObject" method
now synthesize the object (because the someObject ivar doesn't exist
any more in their class, etc) but my product is already out in the
field.
Third Party Class...
SomeObject* someObject {
return [[SomeObject alloc] initWith:...] autorelease];
}
My Class (stays the same because it is already out in the field)...
Now my class is doing a retain and autorelease that is not really
needed because the now non-accessor is following the normal object
ownership contract. If however the third-party developer had used the
retain/autorelease accessor style in the first place this would not
happen. In other words have accessors follow the normal object
ownership contract (at least from the outside worlds POV).
Third Party Class (before)...
SomeObject* someObject {
return [[someObject] retain] autorelease]; //using the simply accessor
scheme
}
or
Third Party Class (after)...
SomeObject* someObject {
return [[SomeObject alloc] initWith:...] autorelease];
}
My Class (before and after)...
SomeObject so = [thirdParty someObject];
[so doSomething];
....
This is one reason I like the retain/autorelease method of accessors.
Now in class or in application facing accessors can follow the simple
method (or any method) if performance is a concern because you usually
control what is going on (or have a higher potential to communicate it
to other on your team). In my opinion external facing classes (used by
external parties) should use the retain/autorelease method based on
suggestions made by Apple (it sounds like Apple plans to do this in
their classes and I think I will as well (I do so already anyway)).
-Shawn
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.