• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CoreData faulting - does it rely on #self?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData faulting - does it rely on #self?


  • Subject: Re: CoreData faulting - does it rely on #self?
  • From: Jim Correia <email@hidden>
  • Date: Thu, 13 Apr 2006 16:37:12 -0400

On Apr 13, 2006, at 12:17 PM, Todd Blanchard wrote:

Does NSManagedObject implement #self as a regular method? If so, I can be assured that my NSObject category method is OK and I won't override it in my subclass. If it insists on adding a non-trivial #self to NSObject, then we have issues. I'd sure like it if someone who knows would answer the question.

I only know what is in the public documentation.

-self is a plain method on NSObject.

http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ ObjC_classic/Protocols/NSObjectProtocol.html#//apple_ref/occ/intfm/ NSObject/self

You also wrote:

I implemented 'self' in my subclass so I could bind some UI on it
using bindings and see the pointer values in some debugging tools of
mine.

Is there a reason you couldn't use the existing method for that purpose, without supplying a new one in a category?


It doesn't appear that NSManagedObject overrides self in today's framework. What we do know is that it is documented that you shouldn't override that method. If you do, even if it works on 10.4.x, there's no guarantee that a) it will in a future OS release and b) that anyone will care if your app breaks because you explicitly did what the documentation said not do to.

My other concern is whether saving turns everything back into a fault.

AFAICT, saving is not documented as turning objects into faults. In my experience, it does not have that side effect.


I don't want this and will need to probably implement didBecomeFault to turn around and call self (if indeed this does trigger faults).

The documentation says that -self can be safely invoked (not your - self, but the default one) without firing a fault, so scratch that plan :-)


-didTurnIntoFault is invoked automatically when an object is turned into a fault. I think you'll find that trying to fire the fault from within this method will be unsuccessful. (I don't remember the exact failure case - this was only happening as the result of a bug which I've long since fixed.)

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


  • Follow-Ups:
    • Re: CoreData faulting - does it rely on #self?
      • From: Todd Blanchard <email@hidden>
References: 
 >Re: CoreData faulting - does it rely on #self? (From: Greg Herlihy <email@hidden>)
 >Re: CoreData faulting - does it rely on #self? (From: Todd Blanchard <email@hidden>)

  • Prev by Date: Re: Progress bar on front NSPanel is grey not blue??
  • Next by Date: NSTextView (NSAttributedString) binding: Is it possible to programmatically change the value source?
  • Previous by thread: Re: CoreData faulting - does it rely on #self?
  • Next by thread: Re: CoreData faulting - does it rely on #self?
  • Index(es):
    • Date
    • Thread