Re: Subclassing NSManagedObject
Re: Subclassing NSManagedObject
- Subject: Re: Subclassing NSManagedObject
- From: mmalcolm crawford <email@hidden>
- Date: Sun, 22 May 2005 16:45:26 -0700
On May 22, 2005, at 4:34 PM, T Reaves wrote:
Shriek. Review Key-Value Coding. The key-value method valueForKey:
is implemented so that [self valueForKey: @"name"] will result in
a call to the name method. Which you define here as [self
valueForKey: @"name"]. Difficulties ensue. The same problem
(filling in the blanks) applies to setValue:forKey:.
willAccessValueForKey:/primitiveValueForKey:/didAccessValueForKey:
are recommended not just to antagonize you, but because they are
necessary. The will/didAccess methods assure you the object store
is in a consistent state while you access it, and the primitive
accessor does a direct-to-the-store access that avoids the kinds
of loops seen above.
NSManagedObject would have to over-ride that, or it would have
the same trouble. You can send those messages to any
NSManagedObject instance to return/set the persistent value.
Correct? And if they are over-ridden in NSManagedObject, I should
be able to use them.
valueForKey: and setValue:forKey: follow the same pattern for
NSManagedObject as they do for other objects. They will first look
for custom accessors. If you implement your methods as you suggested:
- (NSString *)name
{
return [self valueForKey:@"name"];
}
- (void)setName:(NSString *)newName
{
[self setValue:newName forKey:@"name"];
}
you will end up in an infinite loop. It's trivial enough to test...
Or does some kind of funky run-time proxy get created where Apple
implements all those methods?
No. I'm not sure why you're making this a lot more complicated than
necessary? The accessor methods, their behaviour, and the reason you
need to implement them as specified are all explained in the
documentation... What is it you're trying to do differently, or why
is the documentation not a credible reference?
I mean, one of the whole premises of OO coding is reuse. So if I
can send valueForKey: and setValue:forKey: to any NSManagedObject
instance correctly,subclasses should just have to do implementation
specific stuff, then defer to the superclass' implementation. Right?
Not if you're doing something that will interrupt the flow of
execution of the method.
mmalc
_______________________________________________
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