Re: Setters, Getters and efficiency
Re: Setters, Getters and efficiency
- Subject: Re: Setters, Getters and efficiency
- From: Andrei Tchijov <email@hidden>
- Date: Sun, 11 Dec 2005 14:27:05 -0500
On Dec 11, 2005, at 1:39 PM, mmalcolm crawford wrote:
On Dec 11, 2005, at 6:15 AM, Jeff LaMarche wrote:
When binding to a class instance, it will look first for an
accessor method, and only use the instance variable after making
three attempts at using an accessor (e.g. if you bind to foo, it
will look for getFoo, foo, and isFoo) before it will get the
instance variable, so you're actually going to see worse
performance if you don't implement your accessors.
When binding to a managed object (either directly to Core Data, or
to NSManagedObject or a subclass of NSManagedObject), then it will
prefer direct access and will look for an accessor only if it
fails to find something going directly (i.e. if you've got a
virtual accessor).
This is not the case. The access pattern for key-value coding is
the same regardless of the class -- accessor methods are always
tried first (for the search order, see <http://developer.apple.com/
documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/
SearchImplementation.html>; for NSManagedObject, see <http://
developer.apple.com/documentation/Cocoa/Reference/CoreData_ObjC/
Classes/NSManagedObject.html#//apple_ref/occ/instm/NSManagedObject/
setValue:forKey:>).
"...accessor methods are always tried first..." - this is not always
a case. If class overwrite 'valueForKey:/setValue:forKey:' method,
then "all bets are off". For example, NSMutableDictionary does it, so
if you will have class which is derived from it, then all your
setters/getters are going to be ignored by KVC code (unless you
overwrite these 2 methods yourself to restore default semantic).
As for general efficiency; *if* I remember correctly, the first
time an instance of a given class is accessed using KVC, the actual
technique used to get or set the value is cached so that it is not
necessary to perform the search on every subsequent occasion...
On Dec 11, 2005, at 4:37 AM, Bruce Truax wrote:
Cocoa bindings work whether you have specific setters and getters
for a
variable or if you simply define the variable in your header file
with no
specific accessors. Can anyone comment on which method is the most
efficient in terms of execution time?
If my memory serves correctly (see above), then there will be
precious little difference in terms of efficiency -- although you
should use an appropriate profiling tool to check...
But if you're using bindings, then you *need* to use accessor
methods (or at least a set accessor) so that appropriate KVO change
notifications are sent when a value is set (see <http://
developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueObserving/Concepts/AutoVsManual.html>).
Other than that, the main issue you should probably consider is,
what is an appropriate implementation of your accessors. If you
just use instance variables, then KVC simply returns the instance
variable in the get accessor and retains it in the set accessor.
In many cases -- notably for string attributes -- this may not be
what you want; instead you should make a private copy of the new
value. If your application is multi-threaded, you may also want to
use a retain/autorelease-style get accessor (see <http://
www.stepwise.com/Articles/Technical/2002-06-11.01.html>).
For more on Core Data accessor methods, see <http://
developer.apple.com/documentation/Cocoa/Conceptual/CoreData/
Articles/cdAccessorMethods.html> and <http://developer.apple.com/
documentation/Cocoa/Conceptual/CoreData/Articles/cdNSAttributes.html>.
For a broader discussion, see <http://developer.apple.com/
documentation/Cocoa/Conceptual/ModelObjects/index.html>.
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden