On Sep 7, 2015, at 12:01 AM, Alex Hall <mehg...@icloud.com> wrote: > My first step is to make a KVO-compliant backing store, because Swift arrays > won't do the job. As you said, my goal of updating an array and having my > table automagically update itself to match the array just won't happen. What > I need is a class that implements the methods described in the link you > provided,so that bindings will work correctly. Obviously I can use an array > internally, but the interface of the class *must* offer the necessary > methods. I'll call this new class MyKVOCClass, because I'm terrible at naming > things.
It's not particularly that the class must offer the necessary methods. It's that your code must use those methods to modify the array or KVO is not aware of the changes you make. It sounds like you're suggesting making a class just to be an array-like thing that is KVO-compliant. That sounds to me like you're heading down the wrong road. The class which needs to be KVO-compliant is the thing which currently holds the arrays (even if a bit indirectly). That brings us to the next point… > Next, remember that my model is a dictionary of arrays right now. The model > has a single variable that can change to point at any of the arrays in the > dictionary; the table is to display only that selected array (the table is > view-based, one column, no multi-selecting, no editing). Can you explain in some more concrete terms why this level of dynamism is required? What does the dictionary represent in some real-world sense or "business logic"? What do the various arrays represent? Is there a fixed set of arrays or is that variable? What makes one of the arrays current and what does that signify (other than that's the one shown in the table)? What other implications does it have? What do the arrays have in common? Why, other than happenstance or convenience, does it make sense for them to all be part of the same controller? I'm asking because this design strikes me as one which will cause trouble and I'm looking for handholds for a suggested refactoring. I'll wait for more info before getting into the other stuff. Regards, Ken _______________________________________________ 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
