What are the 'primitive' accessors for in Core Data?

From the Core Data Programming Guide (my emphasis):

By default, Core Data dynamically creates efficient public and primitive get and set accessor methods for modeled properties (attributes and relationships) of managed object classes.

Although I've been using Core Data and mogenerator happily since I started on Objective-C, I've开发者_如何学JAVA never had a look at what this means, until an app submission got rejected due to alleged use of private API. Long story about a generated setPrimitiveTypeValue: method, but not what my question is about.

While reading the guide I stumbled on the idea of public and primitive accessors for entity attributes. Another quote, but further down:

For example, given an entity with an attribute firstName, Core Data automatically generates firstName, setFirstName:, primitiveFirstName, and setPrimitiveFirstName:.

What are the primitive accessors for? Is it just so you can assign a BOOL value directly, without wrapping it in an NSNumber? If so, why would mogenerator have gone through the trouble of generating all kinds of <Attribute>Value, set<Attribute>Value:, primitive<Attribute>Value, setPrimitive<Attribute>Value: accessors?

I'm confused, who can help me out?

Related questions:

• Core Data Primitive Accessors (no answers)
• why would I need to use a primitive accessor methods in a core data project? (answered)

As far as I understand it, the primitive method does the actual getting and setting, but does not issue any KVC or KVO notifications (‘willAccessValueForKey‘ and so on). The public method calls the primitive method, but wraps the call in the KVO calls. So from outside the object, you'd typically call the public methods, but if you needed to use the properties of the object for internal reasons (to validate or derive some other property, for example) you would use the primitive methods to avoid firing all the notifications.

I'd welcome any corrections or clarifications on the answer as it is a subject I am interested in but not fully versed in.

@jrturton's answer covered issues regarding Custom Attribute and To-One Relationship Accessor Methods, where public-accessor is straightforward.

In addition, to fully support To-Many Relationship Accessors, in custom implementation, public-accessors may have to call primitive-accessors in combination with NSMutableSet methods (unionSet: and minusSet:), which must be wrapped inside KVO method pairs ( will...did...).