Re: Editing a list of NSMutableStrings
Re: Editing a list of NSMutableStrings
- Subject: Re: Editing a list of NSMutableStrings
- From: Quincey Morris <email@hidden>
- Date: Wed, 02 Mar 2011 12:24:47 -0800
On Mar 2, 2011, at 02:32, Joanna Carter wrote:
> I started by using the NSTableView, together with its delegate methods to supply the list of strings, but what my friend was really after was a way of using NSArrayController to supply the list of strings. This would also allow me to use the same NSArrayController to supply the list to an NSComboBox.
>
> In working through this, I found that I needed to supply a read/write property in a category to NSMutableString.
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.
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.
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.)
> I am writing a small article on this http://carterconsulting.myzen.co.uk/Articles/CreatingAnMruListInXcode.pdf and would value feedback on whether 1. I am on the right track
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.
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.
_______________________________________________
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