Re: Arghh bindings
Re: Arghh bindings
- Subject: Re: Arghh bindings
- From: Rick Mann <email@hidden>
- Date: Mon, 10 Sep 2012 19:29:28 -0700
On Sep 10, 2012, at 19:23 , Quincey Morris <email@hidden> wrote:
> On Sep 10, 2012, at 18:48 , Rick Mann <email@hidden> 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 (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