On 3 Nov 2012, at 12:47, Quincey Morris <quinceymor...@rivergatesoftware.com>
wrote:
> On Nov 2, 2012, at 22:18 , "Gerriet M. Denkmann" <gerr...@mdenkmann.de> wrote:
>
>> Is there a way to make the first NSLog work?
>> I seem to remember that it calls something like debuggingDescription, which,
>> if not overridden calls description.
>>
>> I have no experience with swizzling.
>
> Aren't you making things rather hard for yourself? Logging the array via a
> format string doesn't produce what you want, so just write a function that
> does:
>
> NSString* myArrayAsString (NSArray* array) {…}
>
> and log the return value with a %@ specifier in the normal way.
Well, it is really handy to just write NSLog(@"myArray %@", myArray);
I started this thread, because I was tired of always adding some method like
myArrayAsString.
>
> Adding a category to change the behavior of Cocoa classes seems like a pretty
> bad idea. Adding a category to override an existing method is a really
> terrible idea. (You don't know if the method was already added, or replaced,
> in a category.)
Ok. Point taken.
>
>>> Either way, file a bug.
>> Will do.
>
> Keep in mind that the existing [NSArray description] must go out of its way
> to create the "bad" output. (It clearly isn't using a format specifier for
> string elements, or even invoking the element's 'description' method, which
> would be the obvious things to do.) That suggests to me that the
> extended-style display of characters outside of some basic character set is
> *deliberate*. It may be that it's been historically useful to know when there
> are characters in the string that might not display correctly (or at all) in
> the log output.
Could be. If for example one has a string consisting of 100 THAI CHARACTER MAI
EK one would (if it would be logged as I think it should) see just a single
thing similar to an apostrophe (it is a non-spacing mark).
But then: If this is a valid reason it would also apply to NSLog(@"myString
%@",myString) - but this always prints in a readable way - no silly Unicode
code points in hex.
>
> IOW, your "bad" logging may be someone else's "good" logging.
Maybe.
But: NSArray has descriptionWithLocale:indent: which explicitly states:
If the element is an NSString object, it is used as is.
My string, "as is", is something like "กุญแจ" and not
"\U0e01\U0e38\U0e0d\U0e41\U0e08".
But I think the real reason for the hex stuff is:
NSArray's description "Returns a string that represents the contents of the
array, formatted as a property list."
Obviously this is an "Old-Style ASCII Property List" and this "property list
format uses ASCII for strings".
Which implies that non-ascii must be written as hex.
So the advantage of the current NSArray description style is that one could
read the output "by calling the
propertyListFromData:mutabilityOption:format:errorDescription: method of
NSPropertyListSerialization.".
On the other hand the documentation also states that this format is "still
supported by Cocoa, but for reading only". Which means: no one (not even
NSArray) has any obligation to use this format for output.
So I don't know whether I should file a bug or an enhancement request.
Kind regards,
Gerriet.
_______________________________________________
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
