Re: xcode 2.2 coredata accessors
Re: xcode 2.2 coredata accessors
- Subject: Re: xcode 2.2 coredata accessors
- From: Miguel Sanchez <email@hidden>
- Date: Mon, 14 Nov 2005 20:44:38 -0800
I'd say it's safe to continue using the primitive accessors if they
are more convenient for you and you understand the issues with the
handling of Nil values.
We simply decided to change the code generated by default so
Developer's wouldn't have to deal with these issues if they didn't
want to. After all, one developer's convenience might be another's
annoyance :-)
But KVC supports primitive accessor access, so your data objects
should be fine if you add the appropriate handling calls.
- Miguel
On Nov 14, 2005, at 8:18 PM, Jim Correia wrote:
On Nov 14, 2005, at 9:29 PM, Miguel Sanchez wrote:
The issue is related to handling of nil values for accessors that
use primitive types instead of an object class (NSNumber).
Basically, if you HAVE NOT generated your own accessors, the
default managed object implementation behaves as if the accessors
were taking full objects (NSNumbers). So we decided to make the
change in the generated accessors to use NSNumber and achieve
functional parity with default non-accessor behavior.
Having accessors that use primitive values might make some of the
UI code (specially using bindings) behave a bit different from the
non-accessor case when it comes to interpreting nil values.
Miguel,
Thanks for the explanation. If the accessors are only used by
bindings, NSNumber vs. primitive value isn't a big deal (and the
primitive value accessors offer no real advantage.) However, the
primitive value accessors can be much more convenient for
programmatic access.
Is it safe to continue using primitive value accessors if I'm
willing to implement setNilValueForKey in the appropriate places,
or face the consequences (in the form of
NSInvalidArgumentException)? Or is there more to it than that?
Thanks,
Jim
_______________________________________________
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