Should not use mogenerator in Mac OS 10.5+ ?
-
When developing NSManagedObjects for Mac OS 10.4, after about 25 trips
to Xcode's menu Design > Data Model > Copy Method XXXX-tions to
Clipboard, my wrist got sore and I started using mogenerator [1].
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."
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. And although the "dynamically" generated methods are
"efficient", I assumed that they are still not as efficient as a hard-
coded method. But then, further down, in two highlighted "dire
warning" boxes, I read ...
"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."
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.
My questions: Am I being "strongly encouraged" to ^not^ use
mogenerator in a 10.5+ app? Why?
Thanks,
Jerry Krinock
[1] http://rentzsch.com/code/mogenerator_v1.5 (Be sure to use the
installer, don't just build the tool.)
[2] In "Core Data Programming Guide" > "Managed Object Accessor Methods"
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles
/cdAccessorMethods.html#/
/apple_ref/doc/uid/TP40002154
[3] This "Well, if you insist on hanging yourself.." idiom is familiar
to me in reading Apple documentation. -
On Oct 4, 2008, at 4:11 PM, Jerry Krinock wrote:
> 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.
>
Why? You get type checking and avoid compiler warnings by following
the recommendations in the Programming Guide.
> And although the "dynamically" generated methods are "efficient", IWhy?
> assumed that they are still not as efficient as a hard-coded method.
>
> [3] This "Well, if you insist on hanging yourself.." idiom isWhy are you insisting on hanging yourself?
> familiar to me in reading Apple documentation.
>
mmalc -
On 2008 Oct, 04, at 18:08, mmalc crawford wrote:
> On Oct 4, 2008, at 4:11 PM, Jerry Krinock wrote:
>> And although the "dynamically" generated methods are "efficient", I
>> assumed that they are still not as efficient as a hard-coded method.
>
> Why?
> Why are you insisting on hanging yourself?
Thank you for the answers, mmalc.
If you don't mind, just to be clear, I'd like to rephrase your answer
to my question of whether I should use mogenerator in a 10.5+ project
like this:
On 2008 Oct, 04, at 18:08, mmalc crawford meant:
> "No."
and as to my second question, "Why?"
> The dynamically generated methods are at least as efficient, maybe
> more efficient, than methods generated by mogenerator.
If I got it wrong, mmalc, or if anyone read a different
interpretation, let us know.
Jerry -
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 -
Jerry Krinock (<jerry...>) on 2008-10-4 7:11 PM said:
> So, I don't ^need^ mogenerator, although I still may want to use it
Jerry,
I have been using mogenerator, and have asked myself the same question as you.
I have found the following things about it most useful:
1) when you change your xcdatamodel, running mogenerator is much easier
and less error prone than using Xcode's 'copy declarations/
implementations' feature over and over and over.
2) it adds the newInManagedObjectContext: method which is more readable
than repeating initWithEntity:insertIntoManagedObjectContext all the time.
3) it allows you to specify, in the userInfo dict, the type of a
transformable attribute. This way, accessor declarations will use
NSColor (for example) instead of just id.
4) for scalar types like 'double', it also creates accessors that take
'double' instead of NSNumber.
On the other hand, as Ben stated, some of the accessor code it generates
is entirely unnecessary and less efficient (at runtime). Worse, some of
the code it generates is incorrect. See this recent thread:
<http://www.cocoabuilder.com/archive/message/cocoa/2008/9/24/218788>
Hopefully Jonathan will soon fix mogenerator.
--
____________________________________________________________
Sean McBride, B. Eng <cwatson...>
Mac Software Designer Montréal, Québec, Canada -
I hacked the mogenerator header template file to emit property
declarations for Core Data-generated accessors, and changed the source
template files to not emit any code for accessors. So I get the
convenience of mogenerator together with the supposedly more efficient
Core Data accessors.
I found the template files quite easy to read and to change to my own
specification.
i.
On Oct 5, 2008, at 00:11, Jerry Krinock wrote:
> When developing NSManagedObjects for Mac OS 10.4, after about 25
> trips to Xcode's menu Design > Data Model > Copy Method XXXX-tions
> to Clipboard, my wrist got sore and I started using mogenerator [1].
>
> 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."
>
> 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. And although the "dynamically" generated methods
> are "efficient", I assumed that they are still not as efficient as a
> hard-coded method. But then, further down, in two highlighted "dire
> warning" boxes, I read ...
>
> "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."
>
> 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.
>
> My questions: Am I being "strongly encouraged" to ^not^ use
> mogenerator in a 10.5+ app? Why?
>
> Thanks,
>
> Jerry Krinock
>
> [1] http://rentzsch.com/code/mogenerator_v1.5 (Be sure to use the
> installer, don't just build the tool.)
>
> [2] In "Core Data Programming Guide" > "Managed Object Accessor
> Methods"
> http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles
/cdAccessorMethods.html#/
> /apple_ref/doc/uid/TP40002154
>
> [3] This "Well, if you insist on hanging yourself.." idiom is
> familiar to me in reading Apple documentation.
>
>
