Ah. Which part is kludgy? Parent *parent = ...;
Child *child = ...; parent.activeChild = child; Child *child2 = ...; parent.activeChild = child2; Child *child3 = ...; parent.activeChild = child3; Unless I'm missing something, there is no kludge or workaround with this approach. The code just works. Its ultra clean and doesn't require whatever it is you are doing to clean things up. Having to remember to implement "prepareForDeletion" is a kludge. No? Remember, the best code is no code at all<http://www.codinghorror.com/blog/2007/05/the-best-code-is-no-code-at-all.html> . Again, I'm late to this discussion and I'm surprised it wasn't brought up ... so maybe there is something else to consider - but on the face of it, it seems simpler and easier to maintain. -Luther PS: As an aside, I'm also curious about a comment you made earlier. > I have no need for an inverse, why does Core Data? It seems to me that whether or not you want to explicitly *use* an inverse relationship is fundamentally different than *identifying* that it exists. Core Data needs meta information and will likely be able to function better and more efficiently if you can give it more meta information as opposed to less - whether or not you actually use or leverage that relationship is actually different than identifying it and telling Core Data. For example, If a PROJECT can have only one active TASK at a time ... and a TASK can only belong to one active PROJECT at a time, then the inverse relationship exists - whether or not you want to identify or use it, it still exists. Are you simply opposed to being forced to define that inverse relationship? Feels odd that, instead of accurately defining the inverse relationship ... you instead, decide to implement callback methods to manually implement cleanup code because, you somehow think that is cleaner than accurately defining the inverse data relationship and letting Core Data just handled it for you. No worries, maybe there is some reason why you can't define the inverse relationship that I missed or I'm being too pedantic. I feel like I'm digging too much here! My apologies if that is the case. Sounds like you've already decided your way forward - I was just curious. On Wed, Jun 26, 2013 at 1:20 AM, Rick Mann <rm...@latencyzero.com> wrote: > > On Jun 25, 2013, at 22:57 , Luther Baker <lutherba...@gmail.com> wrote: > > > At the risk of sounding like an idiot for stating the obvious ... why not > > create a (dummy) inverse relationship (Child.activeParent)? No one says > you > > have to use it ... or heck, maybe you want to use it. > > > > Parent.children <-------->> Child.parent > > Parent.activeChild <---------> Child.activeParent > > > > I just tested this and it works as expected. IE: setting > Parent.activeChild > > to different children between saves cleans up both ends of the > relationship > > automatically (each subsequent child's 'activeParent' field was > > automatically cleared when I set a different child to the > > Parent.activeChild property). > > > > I don't know, maybe I missed something. > > > I think that works, and I've done it before, but I find it very kludgey. I > think I prefer the one-way-with-prepareForDeletion approach instead. > > -- > Rick > > > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
