Core Data and Instance Variables
I found this discussion surprising. Some people in the thread expressed concern that Core Data might somehow prevent you from using instance variables. I was shocked to find anybody wants to manage simple value ivars. I think you only stand to benefit by eliminating trivial code like that.It sounds like part of the concern is that it might be too slow to send values through generic KVC methods instead of getting and setting ivars directly. Unless you've decided to not use Cocoa Bindings (which would be unusual for a Core Data app), this seems somewhat irrelevant. NSControllers use KVC extensively.
I imagine NSManagedObject has optimized implementations of common KVC methods. If you're going to put so much emphasis on generic data access, you'd better make sure it performs well. It sounds like they regularly ran some rather large tests during development.
For that matter, using a more generalized protocol doesn't actually mean the result will be slower. I was surprised to find that some applications which were updated to use Cocoa Bindings on Panther were actually faster than the versions built for 10.1/10.2.
Finally, a potentially significant addition in Tiger is the fobjc-direct-dispatch setting:
For some functions (such as objc_msgSend) called very frequently by Objective-C programs, special entry points exist in high memory that may be jumped to directly (e.g., via the "bla" instruction on the PowerPC) for improved performance. The -fobjc-direct-dispatch option will cause such jumps to be generated. This option is only available in conjunction with the NeXT runtime; furthermore, programs built with the -fobjc-direct-dispatch option will only run on Mac OS X 10.4 (Tiger) or later systems.
I'll be curious to find out what some benchmarks say, but this could challenge a lot of assumptions about exactly how long dynamic dispatch takes. I originally heard about this flag from Shawn Erickson, btw.
So all that said, you can still declare instance variables in NSManagedObject subclasses if you really want to. In fact, this is necessarily if you want to have non-object instance variables, such as enums. I still don't understand why you'd do this if it wasn't necessary, though.
Obviously, Core Data doesn't eliminate instance variables for non-data classes like windows, views, but I think it's fantastic that it de-emphasizes the need to write code for every single little value. In particular, it makes large projects much easier to manage.
Core Data and Instance Variables
Posted May 4, 2005 — 2 comments below
Posted May 4, 2005 — 2 comments below
Joakim Danielson — May 21, 05 167
For a class that is used not only with bindings but from other classes as-well I would prefer to have accessor methods even if the just called the the generic KVC methods.
I think the code will be easier to read and it will lower the risk of spelling errors.
Scott Stevenson — May 22, 05 168
That said, I don't think it makes sense to generate accessors for everything just because you can. More code means more to compile and more to maintain.
In many cases, you can address the potential for spelling errors by creating NSString constants for the property names.