RE: Accessors
RE: Accessors
- Subject: RE: Accessors
- From: Kevin Elliott <email@hidden>
- Date: Wed, 7 Aug 2002 10:04:58 -0700
*sigh*. You've just answered your own question. In your first example
where the caller does:
>
SomeObject so = [[[thirdParty someObject] retain] autorelease];
>
You don't need to know _ANYTHING_ about the internal implementation of the
object. The above will always work. Your claim is that you can improve
efficiency by requiring the provider to do this instead (and thus saving a
potentially useless retain autorelease). However, what about the following?
NSMutableArray myArray;
[myArray addObject: [thirdParty someObject]];
If the original class has a simple accessor there are no wasted
retains/autorelease, if it follows your pattern there is.
BUT, all that is beside the point. The only safe behavior is for the client
to retain the object if he's going to need it. Any other pattern relies on
assumptions about the internal implementation of the provider class. Since
the client object is going to be doing a retain anyway, the simple accessor
seems to make the most sense.
Also as an aside, man people have suggested that the following code
str= [thirdParty someObject];
some more code...
[str doSomething];
is inherently unsafe because the underlying value of str may be changed.
Under the "classic" getter/setter model that's not true.
that model is:
someObject: (id) object { return myObject }
setSomeObject: (id) object
{
[myObject autorelease];
[object retain];
myObject= object;
}
Note that myObject is autoreleased, not released. And, because, as a
principle of OO design everyone is setting the value using the accessor, the
returned object will remain valid.
BUT, again, that is irrelevant because you are once again relying on an
internal implementation detail of the class, which is contrary to OO
design!!!
-Kevin Elliott
Software Engineer
CharisMac Engineering
>
----------
>
From: Shawn Erickson
>
Sent: Wednesday, August 7, 2002 09:21
>
To: Marcel Weiher
>
Cc: Chris Ridd; Cocoa Dev
>
Subject: Re: Accessors
>
>
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.
_______________________________________________
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.