Re: Setters, Getters and efficiency
Re: Setters, Getters and efficiency
- Subject: Re: Setters, Getters and efficiency
- From: Bill Cheeseman <email@hidden>
- Date: Sun, 11 Dec 2005 14:01:46 -0500
- Thread-topic: Setters, Getters and efficiency
on 2005-12-11 1:39 PM, mmalcolm crawford at email@hidden wrote:
>
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>).
Plus, there are lots of other issues, having to do with incorporating memory
management, undo management and other things into getters and setters.
As to memory management, for example, it is common to use any of several
design patterns involving retain, release and autorelease in getters and
setters. If you just use an instance variable but memory management issues
are present, you will have to handle the memory management in some other way
-- and that other way may or may not be more efficient than doing it in
getters and setters. In general, the setter and getter design patterns for
memory management are so ingrained in assumptions made by other code that
you will probably pay a huge price in development time trying to design and
implement another technique.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software -
http://www.prefab.com/scripting.html
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
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