On Sep 10, 2012, at 19:23 , Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
> On Sep 10, 2012, at 18:48 , Rick Mann <rm...@latencyzero.com> wrote: > >> The docs say you can implement either insertObject: or insert<Key>. I >> figured it was smart enough to handle the plural-vs-singular change, >> otherwise it's grammatically awkward. > > Well, you were wrong about that. :) > > The intention is that to-many properties should have plural names, and the > accessor name convention reflects this: > > insertObject:inConnectionsAtIndex: > insertConnections:atIndexes: > > Both are grammatically correct if the property name is correct. There is no > 'insertConnection:atIndex:' and nothing in the documentation to support the > idea. Oh! I just mis-read the docs. I could've sworn there was a singular insert<Key>:atIndex:. At least that part makes a bit more sense. >> To this day I'm a little puzzled why a simple NSMutable property needs all >> the extra scaffolding. It really seems like you should get this behavior for >> free, and only need to implement those methods when the thing backing it >> isn't a standard collection. > > It doesn't need "all the extra scaffolding". KVC will peer quite happily into > your instance variables by default. What you don't get for free, in that > case, is KVO compliance for the property. The purpose of providing explicit > accessors is therefore twofold: The docs say this is all for KVC compliance. But because the calls are almost one-to-one when backed by a simple collection, I'm surprised they don't do it for me. In other words, I could write code to dynamically implement -insert<Key>:atIndexes: given a mutable array named <Key>. > 1. It avoids letting KVC introspect your ivars, which is a horrible hack. Not sure I agree here. > 2. It gives you automatic KVO compliance. Nothing really automatic about it: I have to implement those methods. It's not much more work to call -will/didChange: -- 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
