Re: NSDictionary allValues not mutable
Re: NSDictionary allValues not mutable
- Subject: Re: NSDictionary allValues not mutable
- From: Trygve Inda <email@hidden>
- Date: Mon, 18 Oct 2010 15:59:48 +0000
- Thread-topic: NSDictionary allValues not mutable
> On Oct 18, 2010, at 10:22 AM, Trygve Inda wrote:
>
>>> So if the master dictionary and the array for the NSTable are
>>> encapsulated together in a class, you could use NSMutableArray as the
>>> primary structure, and encapsulate a hidden NSMutableDictionary used
>>> only for faster searching. Both are maintained in parallel by the
>>> enclosing class, so there's never any need to ask the dictionary for
>>> its array of values, nor to copy an immutable array to make a mutable
>>> version for table insertion. In short, make a class that
>>> encapsulates all the desired behavior by itself, rather than using a
>>> naked dictionary and the supplementary arrays it makes.
>>
>> How would I go about doing this and still bind to my NSArrayController?
>>
>> I'd have a (singleton) class MyDataClass with two instance vars: myArray and
>> myDictionary both of which would hold the same objects and both would be
>> mutable.
>>
>> So when I bind the NSArrayController to myArray, and the user adds an item
>> via the table (and thusly the add: of NSArrayController), how will my class
>> know that it needs to also add it to the myDictionary?
>
> You are mistaking instance variables for properties. Instance variables are
> implementation details, and nothing outside of your class should be aware of
> them.
>
> Properties are part of your interface, essentially the accessor methods and
> their behavior. (Remember that you can have properties that are not backed by
> instance variables.)
>
> So, you should be thinking in terms of writing accessor methods which present
> a consistent view of the to-many relationship (which happens to be backed by
> an array and a dictionary). Look up the indexed accessor pattern for to-many
> relationships in the KVC documentation
> <http://developer.apple.com/library/mac/documentation/cocoa/Conceptual/KeyValu
> eCoding/Concepts/AccessorConventions.html#//apple_ref/doc/uid/20002174-178830-
> BAJEDEFB>. Also, take a look at "Managing a non-array collection, and
> filtering" on mmalc's page of Cocoa examples
> <http://homepage.mac.com/mmalc/CocoaExamples/controllers.html>.
>
> To keep yourself honest, and to help you learn, try making this to-many
> relationship property have a name completely different from the names of the
> instance variables which back it. Also, I generally recommend that all of
> one's own classes should override +accessInstanceVariablesDirectly to return
> NO. (I regard KVC's ability to bypass your interface and directly access your
> instance variables as A Bad Thing™.)
Yes, I meant properties...
I guess I am just not seeing how my NSArrayController would ties to this. So
I have a class MyDataClass and since my NSTableView is tied to an
NSArrayController, then the NSArrayController needs to get it's data from
MyDataClass.
So is there then a myArray property in MyDataClass that the
NSArrayController binds to?
Or does NSArrayController somehow bind to a non-array property, but one
that responds as if it were an array?
Is there any sample code of this sort of set up?
T.
_______________________________________________
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