• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Apple guys: is the XCode generated CD accessor code decent?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple guys: is the XCode generated CD accessor code decent?


  • Subject: Re: Apple guys: is the XCode generated CD accessor code decent?
  • From: Scott Ellsworth <email@hidden>
  • Date: Fri, 27 May 2005 11:56:01 -0700


On May 27, 2005, at 11:36 AM, Scott Stevenson wrote:


On May 27, 2005, at 11:20 AM, Scott Ellsworth wrote:

In the context menu item for a Core Data attribute, you will find 'copy method implementations to clipboard".
[...]
Does doing this cause a significant performance overhead over plain old valueForKey? It did not seem to on my very simple tests, but those were, as I said, simple. I suspect you guys have a better idea of what valueForKey/setValue:forKey is doing in the background.

It shouldn't, but that's somewhat beside the point.

If you need to do something special (such as return C primitives) when object values are set/get, this is most practical way to do it. I wouldn't generate them "just because," since it means more code to compile and maintain.


(Divergence from original question into coding aesthetics. Skip if you like.)


It is more code, but I, personally, find

int habitability = [testWorld atm] + [testWorld hyd];

easier to parse and understand than

int habitability = [testWorld valueForKey:@"atm"] + [testWorld valueForKey:@"hyd"];

and

[testWorld setAtm:14];

much easier to understand than

[testWorld setValue:[NSNumber numberWithShort:14] forKey:@"atm"];

I believe I find it easier because there is just plain less to parse with a direct setter, so it is easier to recognize as a setter/getter by eye. Thus, a simple thing looks simple.

Further, I see the key first, then the value in the setAtm call, thus I can decide whether the line matters based on whether I am trying to debug something to do with the atm value. If my current task does not involve atm's value, then the entire line can be ignored. With setValue:forKey, I see and parse the value I am going to set before seeing the key I am setting.

I suspect that I will eventually get my eyes trained to ignore the value, and lock onto the key, which will let me do the same processing. I have started chunking objC brackets, so it may happen with colons too.

Scott
_______________________________________________
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


  • Follow-Ups:
    • Re: Apple guys: is the XCode generated CD accessor code decent?
      • From: Scott Stevenson <email@hidden>
References: 
 >Apple guys: is the XCode generated CD accessor code decent? (From: Scott Ellsworth <email@hidden>)
 >Re: Apple guys: is the XCode generated CD accessor code decent? (From: Scott Stevenson <email@hidden>)

  • Prev by Date: Re: NSScrollView problems in Tiger
  • Next by Date: NEWBIE: Working with bindings... a list of infomation
  • Previous by thread: Re: Apple guys: is the XCode generated CD accessor code decent?
  • Next by thread: Re: Apple guys: is the XCode generated CD accessor code decent?
  • Index(es):
    • Date
    • Thread