https://kotlinlang.org logo
#getting-started
Title
# getting-started
j

Joel Denke

02/28/2024, 9:57 AM
Copy code
"FooBarBaz".lowercase().capitalize()
When I use this I ofc get the known capitalize() being deprecated. And it offers me to be replaced with:
Copy code
replaceFirstChar { if (it.isLowerCase()) it.titlecase() else it.toString() })
My question is, why doesnt capitalize doing this under the hood instead and stop deprecating it? Feels wrong adding my own capitalize extension for this, which would interfere with this one. I know I have capitalize(Locale) but I would like to avoid that variant because of Kotlin multiplatform reasons.
v

Vampire

02/28/2024, 10:05 AM
Probably because it would change behavior and thus be a breaking change
j

Joel Denke

02/28/2024, 10:08 AM
The true reason behind this, is that the old capitalize using "wrong" Locale? Or like what can happen in reality?
I guess not nice having capitalize2() or such, until removed the deprecated variant 😄
v

Vampire

02/28/2024, 10:15 AM
"wrong" depends on definition, but yes I'd say. Usually Kotlin uses UTF-8 by default for things, but there it uses the System default locale.
s

Sam

02/28/2024, 10:16 AM
j

Joel Denke

02/28/2024, 10:20 AM
Copy code
// in all targets
String.capitalize()   -> String.replaceFirstChar { if (it.isLowerCase()) it.titlecase() else it }
String.decapitalize() -> String.replaceFirstChar { it.lowercase() }

// in JVM
String.capitalize()         -> String.replaceFirstChar { if (it.isLowerCase()) it.titlecase(Locale.getDefault()) else it }
String.capitalize(locale)   -> String.replaceFirstChar { if (it.isLowerCase()) it.titlecase(locale) else it }
String.decapitalize()       -> String.replaceFirstChar { it.lowercase(Locale.getDefault()) }
String.decapitalize(locale) -> String.replaceFirstChar { it.lowercase(locale) }
Hmm yeah this make my head spin 😄 So for non jVM variants you want to use without Locale even for titlecase? Not entirely sure now when to use what. When do I want to use this,
Copy code
String.replaceFirstChar { if (it.isLowerCase()) it.titlecase() else it }
and when should I use:
capitalize(Locale.Root) or capitalize(Locale.getDefault())
?
From my end I got more confused with the new APIs compared to the other ones. But is it possible for me, like in my case with Kotlin multiplatform to have the correct behaviour automatic aligned correct for all targets I have? Or how do I know when I should use which Locale?
s

Sam

02/28/2024, 10:22 AM
You should use the Locale that corresponds to the language the text you're working with is written in 😉
😜 1
j

Joel Denke

02/28/2024, 10:22 AM
And that I cannot get automatic? 😄
Isnt the language more based on the encoding table its used? I can write Turkish in String but without Turkish chars as of example.
s

Sam

02/28/2024, 10:25 AM
The point is that different languages have different rules for how case conversions work. So you can get different results for the exact same text. If you tell Kotlin that your text is Turkish, and then ask it to capitalize it, you'll get a different result from if you told it the language was English.
Depending on what your app is doing, there are different ways to figure out the locale you should be using. On a mobile app, the system default locale will be the one the user selected in their device settings, but on a web server, you would need to use content negotiation as you're serving different pages to different users.
j

Joel Denke

02/28/2024, 10:27 AM
Right, but isnt that more presentation level of a String so to say? I mean if the String is written in english I would like it to be converted in English and not something else. But I guess would need AI or something to detect language in the String and not using the Locale user having. Most often I need to have conversions in my code being same language as the programming language which is english, being Locale agnostic so to say. In those cases I guess I should be using
String.replaceFirstChar { if (it.isLowerCase()) it.titlecase() else it }
?
In my case I am taking EnumClass.A.name.capitalize where I want to convert enum name to something else, for a new identifier 😛
Not to be used in presentation logic.
s

Sam

02/28/2024, 10:30 AM
Sure, if you use the new (non-deprecated) Kotlin methods it will use the "invariant" locale, which should be fine for what you're describing 👍
j

Joel Denke

02/28/2024, 10:30 AM
As of example when doing "title".capitalize() I do not want if the user has Turkish to do something odd, I want it always to be Title 😄
👍 1
But I guess I would create a new extension called like invariantCapitalize or whatever 😛
And for the other cases, I keep using capitalize(Locale.getDefault or Locale.ROOT)
Like it wasnt complex as it was with date, time, numbers, also need to considering String conversion 😄
I wish there was a kotlinx.formatting library 😄
s

Sam

02/28/2024, 10:38 AM
Kotlin isn't the problem—reality is 😄.
😄 1
💯 1
Honestly it's amazing how good a job the Unicode project has done at imposing some sort of structure on the insanity that is human communication
j

Joel Denke

02/28/2024, 10:57 AM
Yeah I totally agree 😄 I just wished there was more things solved from JVM/Java world in the past, no one at Oracle adressed or ignored for very long time, which now inherited by Kotlin. Simple things as BigDecimal formatting or input from user convert to Locale keyboard input, or formatting timezone based Instant to human readable ISO formats. Its always about Locale 😄 I just wished kotlinx and Kotlin provide more awesome stuff like kotlinx-datetime not provide agnostic formatting of time and dates in upcoming 0.6.0 release. I would like to have everything enforce in ISO formats everywhere, and not accept anything else. But also in JVM world how to copy Locales in Android has been, very special over time as well, to have Threeten or Jodatime cover up, or using desugaring to have polyfills. Sorry off topic maybe 😄
k

Klitos Kyriacou

02/28/2024, 12:25 PM
Honestly it's amazing how good a job the Unicode project has done at imposing some sort of structure on the insanity that is human communication
It bugs me that today's ultra-modern computing carries a lot of baggage from the past, from even before computers existed. Unicode is one example of this. There are many ways to indicate a new line: LF, CR, CR+LF, NEL (U+0085), LS (U+2028) and probably a few others I haven't thought of. Qwerty keyboards are another example, with key positions optimized for mechanical typewriters. I wish we could just start afresh, but I know that's unfortunately unrealistic.