RESOLVED FIXED152715
TextBreakIterator uses an internal implementation detail of NSLocale
https://bugs.webkit.org/show_bug.cgi?id=152715
Summary TextBreakIterator uses an internal implementation detail of NSLocale
Myles C. Maxfield
Reported 2016-01-04 15:24:46 PST
TextBreakIterator uses an internal implementation detail of NSLocale
Attachments
Patch (1.67 KB, patch)
2016-01-04 15:25 PST, Myles C. Maxfield
no flags
Patch (1.70 KB, patch)
2016-01-04 15:26 PST, Myles C. Maxfield
no flags
Myles C. Maxfield
Comment 1 2016-01-04 15:25:37 PST
Myles C. Maxfield
Comment 2 2016-01-04 15:26:10 PST
Myles C. Maxfield
Comment 3 2016-01-04 15:26:39 PST
WebKit Commit Bot
Comment 4 2016-01-04 16:42:59 PST
Comment on attachment 268242 [details] Patch Clearing flags on attachment: 268242 Committed r194566: <http://trac.webkit.org/changeset/194566>
WebKit Commit Bot
Comment 5 2016-01-04 16:43:03 PST
All reviewed patches have been landed. Closing bug.
Darin Adler
Comment 6 2016-01-13 08:53:58 PST
Comment on attachment 268242 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=268242&action=review > Source/WebCore/platform/text/mac/TextBreakIteratorInternalICUMac.mm:41 > + NSArray *languagesArray = [NSLocale preferredLanguages]; To be consistent with the usage in the rest of this file it would be better to call CFLocaleCopyPreferredLanguages rather than [NSLocale preferredLanguages]. There is a change in behavior here: the NSLocale/CFLocale functions create a new array with the result of CFLocaleCreateCanonicalLanguageIdentifierFromString on each item in the array. That means that: 1) The code in this function that checks if the item from the array is an NSString is no longer needed since the NSLocale/CFLocale function guarantees it will return an array of strings, with no objects of other types. 2) The code below in two different functions that calls canonicalLanguageIdentifier on the result of this function is no longer needed; the result of this function is already guaranteed to be a canonical language identifier. I suggest moving the call to CFLocaleCreateCanonicalLanguageIdentifierFromString into the textBreakLocalePreference function and removing the canonicalLanguageIdentifier function entirely.
Myles C. Maxfield
Comment 7 2016-01-13 16:30:30 PST
Comment on attachment 268242 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=268242&action=review >> Source/WebCore/platform/text/mac/TextBreakIteratorInternalICUMac.mm:41 >> + NSArray *languagesArray = [NSLocale preferredLanguages]; > > To be consistent with the usage in the rest of this file it would be better to call CFLocaleCopyPreferredLanguages rather than [NSLocale preferredLanguages]. > > There is a change in behavior here: the NSLocale/CFLocale functions create a new array with the result of CFLocaleCreateCanonicalLanguageIdentifierFromString on each item in the array. That means that: > > 1) The code in this function that checks if the item from the array is an NSString is no longer needed since the NSLocale/CFLocale function guarantees it will return an array of strings, with no objects of other types. > 2) The code below in two different functions that calls canonicalLanguageIdentifier on the result of this function is no longer needed; the result of this function is already guaranteed to be a canonical language identifier. I suggest moving the call to CFLocaleCreateCanonicalLanguageIdentifierFromString into the textBreakLocalePreference function and removing the canonicalLanguageIdentifier function entirely. http://trac.webkit.org/changeset/195001
Myles C. Maxfield
Comment 8 2016-01-13 22:22:59 PST
Comment on attachment 268242 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=268242&action=review >>> Source/WebCore/platform/text/mac/TextBreakIteratorInternalICUMac.mm:41 >>> + NSArray *languagesArray = [NSLocale preferredLanguages]; >> >> To be consistent with the usage in the rest of this file it would be better to call CFLocaleCopyPreferredLanguages rather than [NSLocale preferredLanguages]. >> >> There is a change in behavior here: the NSLocale/CFLocale functions create a new array with the result of CFLocaleCreateCanonicalLanguageIdentifierFromString on each item in the array. That means that: >> >> 1) The code in this function that checks if the item from the array is an NSString is no longer needed since the NSLocale/CFLocale function guarantees it will return an array of strings, with no objects of other types. >> 2) The code below in two different functions that calls canonicalLanguageIdentifier on the result of this function is no longer needed; the result of this function is already guaranteed to be a canonical language identifier. I suggest moving the call to CFLocaleCreateCanonicalLanguageIdentifierFromString into the textBreakLocalePreference function and removing the canonicalLanguageIdentifier function entirely. > > http://trac.webkit.org/changeset/195001 http://trac.webkit.org/changeset/195006
Note You need to log in before you can comment on or make changes to this bug.