Re: printing arrays
Re: printing arrays
- Subject: Re: printing arrays
- From: "Gerriet M. Denkmann" <email@hidden>
- Date: Sun, 04 Nov 2012 00:25:38 +0700
On 3 Nov 2012, at 12:47, Quincey Morris <email@hidden> wrote:
> On Nov 2, 2012, at 22:18 , "Gerriet M. Denkmann" <email@hidden> 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 (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