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 protected])
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 [email protected]
