Crash chuzzling an NSBigMutableString about chuzzlekit HOT 3 CLOSED

Hmm. I guess we could call mutableCopy in the mutable path. Hah.

Otherwise we can remove the mutable paths. They aren't important IMO. They were added in a pull request.

I've tested this kind of thing with mutableArray, and IIRC the objects respond to the mutable selectors, but they crash if you call them, so it's a strange area of objc.

Since we are categories we can't have a category for NSString and NSMutableString, or at least, in my testing, this did not work, hence the strange checks for mutability in the methods we have.

I'm leaning towards removing the mutability parts, I think it is not possible to properly support them.

from chuzzlekit.

Also, you didn't want the textField’s string to be chuzzled anyway! I'm not sure if we should consider this ChuzzleKit’s fault or UIKit’s though.

Still I feel sticking with immutability is what I intended for this library, and what people expect.

from chuzzlekit.

Yeah, I hadn't realized it returned a pointer to it's representation string, so I fixed that in our code by making an immutable copy. It's something I'll be sure to remember in the future when using UITextView.

I think ideally chuzzle would avoid mutating objects in place, as that would seem to be safest.

I'm personally not sure about how it does whitespace trimming either. What's happening in my case is the string that's a URL parameter was a user-entered value in a text field. It turns out that I do my own whitespaces trimming, but who's to say that some app doesn't want to include spaces or newlines or tabs at the beginning/end of the string it's passing as a URL parameter?

from chuzzlekit.