• 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
Good way to have default relationship to override nil?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Good way to have default relationship to override nil?


  • Subject: Good way to have default relationship to override nil?
  • From: Jim Thomason <email@hidden>
  • Date: Wed, 20 Aug 2014 14:41:36 -0500

I have a set of relationships:

Foo.proxy <----> Foo.proxyFor

1-1 mapping. The way that the data is structured, a Foo object may be a
proxy for another one. However, the proxy is not required, in which case
the original Foo object should be returned.

I'd tried to set this up by creating a custom getter that returns self if
the relationship is nil.

-(Foo*) proxy {


    [self willAccessValueForKey:@"proxy"];

    Foo* prx = [self primitiveValueForKey:@"proxy"];

    [self didAccessValueForKey:@"proxy"];


    return prx != nil

        ? prx

        : self;


}


In terms of accessing it, this works fine. However, whenever I try to set a
new proxy:


[someFooObj setProxy : otherFooObj];


All hell breaks loose. It sets off a cascade that roughly seems to do the
following (possibly redundantly for a few of these calls):


[someFooObj setProxy: otherFooObj];

[someFooObj setProxy: nil];

[someFooObj setProxy: someFooObj];


After a lot of hunting, I discovered that it was the KVO notes which were
fired by setProxy - once didChangeValueForKey:@"proxy" hit, then it set off
a chain reaction of additional setProxy calls, with nil and self.


I finally fixed this by -not- overriding the CoreData setter, and instead
creating a new one:


-(Foo*) defaultProxy {

  return [self proxy] != nil

    ? [self proxy]

    : self;

}


And then replaced all calls to


[someFooObj proxy]


with


[someFooObj defaultProxy];


After that it all magically works. I can do it this way, but it just feels
a little clunky to have to have a separately named method that is not the
actual property name.


So I have two questions:


1) First off, why does this actually break so badly? I'm never actually
calling setProxy: directly, it's just somehow indirectly called over and
over from within the didChangeValueForKey: notification inside of it.


2) Is there a better way I could model this so as not to need a custom
separately named method? I'm pretty early in my dev cycle, so it's really
easy to refactor this to something else, I'm just stumped for ideas.


Many thanks,


-Jim....
_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden


  • Follow-Ups:
    • Re: Good way to have default relationship to override nil?
      • From: Jerry Krinock <email@hidden>
  • Prev by Date: Re: Issuing NSTextField action message
  • Next by Date: Re: Issuing NSTextField action message
  • Previous by thread: Photo Editing extension needs lots of memory and got crashed. How to avoid it?
  • Next by thread: Re: Good way to have default relationship to override nil?
  • Index(es):
    • Date
    • Thread