Re: Core Data attributes and reserved names...
Re: Core Data attributes and reserved names...
- Subject: Re: Core Data attributes and reserved names...
- From: Matthew Firlik <email@hidden>
- Date: Sun, 20 Aug 2006 01:12:17 -0700
On Aug 19, 2006, at 2:12 PM, Michael Ash wrote:
On 8/19/06, mmalc crawford <email@hidden> wrote:
Properties
[...] Note that a property name cannot be the same as any no-
parameter
method name of NSObject or NSManagedObject, for example, you cannot
give a property the name "description" (see NSPropertyDescription).
"Note that a property name cannot be the same as any no-parameter
method name of NSObject or NSManagedObject. [...]"
This seems sort of scary. Does this mean that if Apple ever adds a new
method to NSObject, it could potentially break any CoreData
application that just happened to use the unlucky attribute name, even
though that name was 100% fine when the app was built?
Yes. However, it's worth noting this is not just a Core Data /
managed object issue: any NSObject subclass is susceptible to this
kind of problem. Anyone can implement a category which (unknowingly
or unwittingly) overlaps with a method on your class, causing problems
for everyone. Obviously, Apple (and I can vouch specifically for the
Core Data team) tries *very hard* not to create this situation -- but
of course the design of managed objects (supporting whatever property
names a developer wants to define) makes this challenging.
The validation provided by the modeling tools is functionally limited
by the available information. At it's core, the modeling tools in
Xcode search the *available* runtime -- that being the Cocoa umbrella
and all other frameworks linked by the IDE -- for conflicting property
names. There is unfortunately no simple means for the modeling tools
to know all of the frameworks and/or libraries to be aware of -- even
if it looked in those linked into the target project, it wouldn't be
able to search those dynamically loaded or linked by other related
projects. So while the tools provide some insight, it isn't meant to
be absolute coverage.
There are means to proactively watch for or assist with debugging
property conflicts. If you define the environment variable
"OBJC_PRINT_REPLACED_METHODS" (set it to any value), the Objective-C
runtime will print out a list of the methods which are replaced
(meaning, overlapping) when your application starts up. (Setting the
"OBJC_HELP" environment variable will print out a list of all the
available runtime-assistance flags.) The resulting output in the log
looks something like:
objc[6058]: REPLACED: -[NSObject retain] by category
MyLudicrousOverride
(IMP was 0x90d04466, now 0x1f7a)
While this doesn't give you file-and-line number information, it does
let you know problems are likely ahead. It's certainly worth putting
this variable into a unit testing or development configuration and
enabling it from time to time.
- matthew
_______________________________________________
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