• 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: Should not use mogenerator in Mac OS 10.5+ ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

re: Should not use mogenerator in Mac OS 10.5+ ?


  • Subject: re: Should not use mogenerator in Mac OS 10.5+ ?
  • From: Ben Trumbull <email@hidden>
  • Date: Sun, 5 Oct 2008 14:43:21 -0700

Jerry,

Now, developing for Mac OS X 10.5+, I read that "On Mac OS X v10.5,
Core Data dynamically generates efficient public and primitive get and
set attribute accessor methods and relationship accessor methods for
managed object classes."

Yes.

So, I don't ^need^ mogenerator, although I still may want to use it in
order to get type checking and generate code needed to avoid compiler
warnings.

A simple @property declaration will get you all the type checking, and warning avoidance you need with the dynamic accessors. The Design -> Data Model -> Copy Obj-C 2.0 Method Interfaces will do that. You can use multiple selection on your entity's properties to save on RSI.


And although the "dynamically" generated methods are "efficient", I assumed that they are still not as efficient as a hard- coded method.

You would assume incorrectly. The dynamic properties on NSManagedObject are faster than the code you can write against the API. Although imprecise, you might imagine a lot of IMP caching and function inlining could be done. There are optimizations when we can tell a priori that you are using our default behavior, as opposed to a custom accessor whose code might do anything.


"Important: You are strongly encouraged to use dynamic properties
(that is, properties whose implementation you specify as @dynamic)
instead of creating custom implementations for standard or primitive
accessor methods."

That's a bit more dire than it needs to be.

But I don't see any reasons given.  Paradoxically these boxes seemed
to be followed by instructions detailing how to do what was just
recommended against doing [3], including code examples of standard
accessors which look like what I get out of mogenerator.

We are trying to strongly discourage people from creating default accessors that don't do anything interesting. If you have custom code, great, use it. But creating accessors just for type safety or the misapprehension that compiled accessors will be faster is not as good as just using dynamic properties.


My questions: Am I being "strongly encouraged" to ^not^ use mogenerator in a 10.5+ app? Why?

If you're going to customize those accessors, it's not just fine, but intended. If you're just going to do a bunch of code generation for the sake of having source code for your accessors, then yes, you are being discouraged.


[3] This "Well, if you insist on hanging yourself.." idiom is familiar to me in reading Apple documentation.


This encouragement is not in that spirit. You could file a bug to clear up the implications of this piece of documentation.

- Ben

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: How do I guarantee that an object is dealloced on the main thread?
  • Next by Date: Computer icon on Leopard
  • Previous by thread: Re: Should not use mogenerator in Mac OS 10.5+ ?
  • Next by thread: NSURLConnection willSendRequest: not behaving as expected on a 302 response - no further response after nil return
  • Index(es):
    • Date
    • Thread