• 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
KVC, KVO and dot notation. Was: whether to use core data...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

KVC, KVO and dot notation. Was: whether to use core data...


  • Subject: KVC, KVO and dot notation. Was: whether to use core data...
  • From: Colin Howarth <email@hidden>
  • Date: Sun, 4 Oct 2009 00:45:59 +0200

On 3 Oct, 2009, at 23:51, Klaus Backert wrote:
On 3 Oct 2009, at 22:06, Colin Howarth wrote:

If you use dot notation and properties, you are using the -value and -setValue: accessor methods, which is KVC compliant and means that KVO bits will get notified, no?

No.

From the documentation "The Objective-C 2.0 Programming Language":
----------
You can think of a property declaration as being equivalent to declaring two accessor methods. Thus
@property float value;
is equivalent to:
- (float)value;
- (void)setValue:(float)newValue;
A property declaration, however, provides additional information about how the accessor methods are implemented
----------


Accessing using dot notation

myObject.value = x;
x = myObject.value;

is equivalent to accessing using conventional notation

[myObject setValue: x];
x = [myObject value];

This all may be something which is KVC compliant -- or it may not be --, as you can see in the "Key-Value Coding Programming Guide", chapter "Ensuring KVC Compliance".


OK, since this is perhaps a relevant example of what I was talking about, let's compare my off the cuff sentence with the Apple Docs:

If you use dot notation and properties, you are using the -value and -setValue: accessor methods, which is KVC compliant and means that KVO bits will get notified, no?




Ensuring KVC Compliance

In order for a class to be considered KVC compliant for a specific property, it must implement the methods required for valueForKey: and setValue:forKey: to work for that property.

Attribute and To-One Relationship Compliance

For properties that are an attribute or a to-one relationship, this requires that:

• Your class implements a method named -<key>, -is<Key>, or has an instance variable <key> or_<key>.
• If the property is mutable, then it should also implement -set<Key>:.
• Your implementation of the -set<Key>: method should not perform validation.
• Your class should implement -validate<Key>:error: if validation is appropriate for the key.



<<< I have an instance variable named <key>. The methods -<key> and - set<Key>: have been synthesized. Validation is inappropriate >>>




Indexed To-Many Relationship Compliance

For indexed to-many relationships, KVC compliance requires that your class:

• Implements method named -<key> that returns an array.
• Or has an array instance variable named <key> or _<key>.
• Or implements the method -countOf<Key> and one or both of - objectIn<Key>AtIndex: or -<key>AtIndexes:.
• Optionally, you can also implement -get<Key>:range: to improve performance.



<<< I have an array instance variable named <key>. Performance is not an issue. >>>




For a indexed ordered to-many relationship, KVC compliance requires that your class also:

• Implement one or both of the methods -insertObject:in<Key>AtIndex: or -insert<Key>:atIndexes:.
• Implement one or both of the methods -removeObjectFrom<Key>AtIndex: or -remove<Key>AtIndexes:.
• Optionally, you can also implement - replaceObjectIn<Key>AtIndex:withObject: or - replace<Key>AtIndexes:with<Key>: to improve performance.


<<< Oooh, tut, tut. That should probably read "For a MUTABLE indexed ordered to-many relationship", or, at least, "For AN indexed ..." >>>


Unordered To-Many Relationship Compliance

For unordered to-many relationships, KVC compliance requires that your class:

• Implements method named -<key> that returns a set.
• Or has an set instance variable named <key> or _<key>.
• Or implements the methods -countOf<Key>, -enumeratorOf<Key>, and - memberOf<Key>:.



<<< Ah. Little typo: "Or has A set". I don't have any set instance variables, but if I did, they would be named <key>. >>>




For a mutable unordered to-many relationship, KVC compliance requires that your class also:

• Implement one or both of the methods -add<Key>Object: or -add<Key>:.
• Implement one or both of the methods -remove<Key>Object: or - remove<Key>:.
• Optionally, you can also implement -intersect<Key>: and -set<Key>: to improve performance.


<<< I don't have a "mutable unordered to-many relationship" aka as a "set" >>>



So, on the assumption that I have the relevant instance variables, which I do, my statement is basically correct. Except that it doesn't cover instance variables that are "mutable unordered or indexed and/or ordered to-many relationships" - but then it (my statement) is a little shorter, isn't it?


--colin

_______________________________________________

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


References: 
 >whether to use core data... (From: Colin Howarth <email@hidden>)
 >Re: whether to use core data... (From: Sherm Pendley <email@hidden>)
 >Re: whether to use core data... (From: Colin Howarth <email@hidden>)
 >Re: whether to use core data... (From: Mike Abdullah <email@hidden>)
 >Re: whether to use core data... (From: Colin Howarth <email@hidden>)

  • Prev by Date: Re: Auto Install Login Item
  • Next by Date: Re: View shifted up on iPhone simulator
  • Previous by thread: Re: whether to use core data...
  • Next by thread: Re: whether to use core data...
  • Index(es):
    • Date
    • Thread