Hi Quincey Many thanks for taking the time to look at this issue.
> This has come up at least once before, and the approach you're using was > suggested. I think it has some academic interest, but I'm not sure that it's > of great use in practical applications. I would agree that it is not something that I would normally consider as major part of application design. As someone who is very well known in the Delphi world, I seem to be doing quite a bit of "evangelism" about Mac development and most Delphi developers haven't even heard of MVC, design patterns and separation of concerns. The kind of RAD development that Delphi (and Visual Studio) seem to encourage tends to end up with all the code in the form classes; people are used to doing everything "in the UI", filling list boxes with strings in the form designer and having to get the strings back from the control when required for manipulation. My aim, in the tutorial, was to show non-Mac programmers that they could feel "safe", in that they could, in theory, easily display and manipulate a list of strings. Normally, as you allude, I would expect to be using the NSTableView and NSComboBox to be displaying and choosing "proper" objects, based on a particular property. > One thing I notice is that your transformation of "string" into a > NSMutableString property *isn't* KVO compliant. It would be if all the other > NSMutableString methods modified the underlying string data via 'setString:', > or issued 'will/didChangeValueForKey:' pairs. I'd bet they don't. You have a good point there. It definitely comes into the classification of a kludge :-) Nonetheless, I a not expecting anything to be observing the change to the "string property"; after all, the whole point of the exercise is mainly to allow manipulation and editing of lists of NSMutableString instances in controls, rather than being KVC-compliant as in editing properties of other objects. > The other issue is that it almost always turns out that the string fits in a > larger design which makes it natural for the string *value* to be a property > of some other object, so the hack of making it a property of NSMutableString > isn't really necessary. That's why I think your example is a bit academic. > (Of course, you can probably find some real examples where the "string" > property approach feels natural.) Agreed; see my comments above :-) > I don't understand why you're using 'will/didChangeValueForKey:@"values" > withSetMutation:NSKeyValueUnionSetMutation usingObjects: ...' for a property > that's a NSArray. The documentation says these methods are for "unordered" > collection properties -- i.e. NSSet properties. Chances are it's harmless > doing this the wrong way, but I wouldn't be surprised to see some UI > misbehaviors show up at some point. Hmmm, yes I did realise the difference in terminology but… it works!!! Would it be sufficient to simply use will/didChangeValueForKey, without the set mutation part, to prompt the NSArrayController to update itself? > I think there's also a conceptual problem in your use of NSMutableString > objects to populate your list. In a lot of cases, when a property value is to > be thought of as an attribute or "simple" value, the property value objects > should be immutable. (Consider, for example, the problem you'd face if you > tried to rework your tutorial to be a list of NSNumber objects.) What happens > if one of your mutable strings "escapes" from the list context (is returned > as a NSString* value of some method, for example), and is used elsewhere? > Would it be correct that mutating the original string in its list should > modify the value that had been passed on to a different context? Maybe yes, > maybe no. There's a small can of worms lurking there. Oh yes, plenty of worms :-) But that's what you end up with when you are trying to help people get out of their "all in one" approach to software design and into techniques like MVC. Joanna -- Joanna Carter Carter Consulting _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
