Comments on: Accessor Methods, Part 2 http://nslog.com/2003/05/17/accessor_methods_part_2 The Weblog of Erik J. Barzeski Wed, 23 May 2012 23:05:21 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Erik J. Barzeski http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3320 Erik J. Barzeski Sat, 21 Jun 2003 22:43:57 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3320 I'd hardly call that more condensed. I'd hardly call that more condensed.

]]> By: mmalc crawford http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3319 mmalc crawford Sat, 21 Jun 2003 17:54:54 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3319 Scott wrote: "You should see if you can get a condensed/simplifed version of this onto CocoaDevCentral." There's been a "more condensed version" at <a href="http://www.stepwise.com/Articles/Technical/2002-06-11.01.html/">http://www.stepwise.com/Articles/Technical/2002-06-11.01.html</a> for some time... mmalc Scott wrote:

"You should see if you can get a condensed/simplifed version of this onto CocoaDevCentral."

There's been a "more condensed version" at http://www.stepwise.com/Articles/Technical/2002-06-11.01.html for some time...

mmalc

]]> By: Scott Stevenson http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3318 Scott Stevenson Sun, 18 May 2003 22:49:51 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3318 You should see if you can get a condensed/simplifed version of this onto CocoaDevCentral. Maybe the same basic idea without the surrounding discussion. - Scott You should see if you can get a condensed/simplifed version of this onto CocoaDevCentral. Maybe the same basic idea without the surrounding discussion.

- Scott

]]> By: Personal vs. Private | NSLog(); http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3321 Personal vs. Private | NSLog(); Sun, 18 May 2003 21:49:54 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3321 Jamie's written in a far better manner than I could an entry discussing the self-censorship one must apply to their blogging. She also links to... Jamie's written in a far better manner than I could an entry discussing the self-censorship one must apply to their blogging. She also links to...

]]> By: Anonymous http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3317 Anonymous Sun, 18 May 2003 01:20:28 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3317 Even then you are better off using the accessor. If the accessor only does return foo; you can save yourself the method dispatch, but once that accessor changes to become more complicated you have to find everywhere you accessed foo and go through the accessor. If the accessor does something more complicated than return foo; then not using the accessor means you have to replicate that logic all over the place. Even then you are better off using the accessor. If the accessor only does return foo; you can save yourself the method dispatch, but once that accessor changes to become more complicated you have to find everywhere you accessed foo and go through the accessor. If the accessor does something more complicated than return foo; then not using the accessor means you have to replicate that logic all over the place.

]]> By: Erik J. Barzeski http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3316 Erik J. Barzeski Sun, 18 May 2003 00:59:54 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3316 The general rule of thumb is to use your object's accessor methods, particularly in the set methods. After all, your set methods may do some sanity checking of their own (<code>!= nil</code> for example) that you don't want to circumvent. Besides, you'd have to inline your set method anyway (or you'd leak or something). Customized "gets" aren't terribly abundant, but they can happen, and it's better to know later down the line that everything is going through your accessors than to track down the ones that aren't and add some logic/sanity-checks to those as well. Very rarely would I recommend accessing instance variables directly. The general rule of thumb is to use your object's accessor methods, particularly in the set methods. After all, your set methods may do some sanity checking of their own (!= nil for example) that you don't want to circumvent. Besides, you'd have to inline your set method anyway (or you'd leak or something). Customized "gets" aren't terribly abundant, but they can happen, and it's better to know later down the line that everything is going through your accessors than to track down the ones that aren't and add some logic/sanity-checks to those as well.

Very rarely would I recommend accessing instance variables directly.

]]> By: Phil Larson http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3315 Phil Larson Sun, 18 May 2003 00:47:48 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3315 On the topic of accessors: should you use your class' accessors when you're writing other methods in that class or is it alright to call the member variables directly? On the topic of accessors: should you use your class' accessors when you're writing other methods in that class or is it alright to call the member variables directly?

]]> By: ssp http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3314 ssp Sat, 17 May 2003 20:51:49 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3314 Nice one. Reminds me of why I've been suspicious about Cocoa/Objective-C: You have to worry about memory stuff. Sometimes I actually started to <em>like</em> that as it forces me to be more clear about object ownership etc. and to not simply rely on things 'going away' at some stage. On the other hand, it does add an extra layer of complexity which I find quite absurd in the <code>[[object retain] autorelease]</code>. Not very æsthetic. If you needn't worry about memory that much you could probably focus more on whether you want to set/retrieve the object or merely its data (i.e. <code>copy</code> it). That is an important conceptual distinction, rather than a technical one: Do I need the data here or the correct reference? As you point out, frequently you'll want a reference to the object, such as the superview or the delegate, in other cases you'll actually want the data and you'll want a copy of it that cannot be modified by anyone else. Thus I suggest adding - (NSString *)title { return [[title copy] autorelease]; } to your zoo of accessor methods, for the case where you want to return the value rather than the object. I read somewhere the - very plausible - recommendation to use this wherever you are not 100% sure about the future usage of your class to prevent that kind screwing things up you illustrate in the five step example. I think the difference between sharing the actual object or only passing on its data isn't made clear in many texts. And I find that it's another place where it can be helpful to sit down and ask yourself "What do I want to set/retrieve?" and be more clear about what your program is doing. Of course as a corollary of this, you'll end up being very keen to implement <code>NSCopying</code> for your classes, and all those other nifty things :) What do you think about <code>NSNumber</code>s, btw? I'm always disappointed that you can't do computations with them and have to use those old-fashioned <code>int</code>s and <code>double</code>s for that purpose, where you'd want to use NSNumbers for everything else - meaning that you'll end up converting things back and forth which is ugly. ... and of course you'll have less lines of code starting with a bracket. I don't like those. They look like you're writing your code in C. Eeeek. Nice one.

Reminds me of why I've been suspicious about Cocoa/Objective-C: You have to worry about memory stuff.

Sometimes I actually started to like that as it forces me to be more clear about object ownership etc. and to not simply rely on things 'going away' at some stage.

On the other hand, it does add an extra layer of complexity which I find quite absurd in the [[object retain] autorelease]. Not very æsthetic. If you needn't worry about memory that much you could probably focus more on whether you want to set/retrieve the object or merely its data (i.e. copy it). That is an important conceptual distinction, rather than a technical one: Do I need the data here or the correct reference?

As you point out, frequently you'll want a reference to the object, such as the superview or the delegate, in other cases you'll actually want the data and you'll want a copy of it that cannot be modified by anyone else. Thus I suggest adding

- (NSString *)title

{

return [[title copy] autorelease];

}

to your zoo of accessor methods, for the case where you want to return the value rather than the object. I read somewhere the - very plausible - recommendation to use this wherever you are not 100% sure about the future usage of your class to prevent that kind screwing things up you illustrate in the five step example.

I think the difference between sharing the actual object or only passing on its data isn't made clear in many texts. And I find that it's another place where it can be helpful to sit down and ask yourself "What do I want to set/retrieve?" and be more clear about what your program is doing.

Of course as a corollary of this, you'll end up being very keen to implement NSCopying for your classes, and all those other nifty things :)

What do you think about NSNumbers, btw? I'm always disappointed that you can't do computations with them and have to use those old-fashioned ints and doubles for that purpose, where you'd want to use NSNumbers for everything else - meaning that you'll end up converting things back and forth which is ugly.

... and of course you'll have less lines of code starting with a bracket. I don't like those. They look like you're writing your code in C. Eeeek.

]]> By: Buzz Andersen http://nslog.com/2003/05/17/accessor_methods_part_2#comment-3313 Buzz Andersen Sat, 17 May 2003 18:48:03 +0000 http://nslog.com/2003/05/17/accessor_methods_part_2/#comment-3313 Nice! An excellent summary, and very informative--thanks! Nice! An excellent summary, and very informative--thanks!

]]>