Recently, i've wanted to use capitalize() function.
When I did so, a warning occured:
'capitalize(): String' is deprecated. Use replaceFirstChar instead.
The suggested replaceFirstChar feels quite long and complicated:
input.replaceFirstChar { if (it.isLowerCase()) it.titlecase(Locale.getDefault()) else it.toString() }
Although everything works fine with capitalize(), i've been just wondering what the reason for deprecated warning is, if there's any problem with it and how can i solve this.
There is no problem with the code per se. The "issue" is what capitalize means for all of the possible languages/characters/platforms/locales.
The doc even says why it is deprecated.
The title case of a character is USUALLY the same as its upper case
with several exceptions. The particular list of characters with the
special title case form depends on the underlying platform.
If you follow all of the reasoning why it is deprecated you reach isTitleCase where you will have an example of characters in languages where the character should not be "upper cased".
Capitalization is writing a word with its first letter as a capital letter (uppercase
letter) and the remaining letters in lower case, in writing systems
with a case distinction.
There are a few good examples and explanations for different languages on Letter case Wiki
e.g.
The German letter "ß" formerly existed only in lower case.
Related
I tried to find literature on this but couldn't seem to find any. Examples in PEP8 do not include digits (I'm using Python, but this question should be language agnostic).
In snake_case, I would write variable1, variable2, and this is fine to me as the number stand out.
However, in ALL_CAPS, I instinctively write VARIABLE_1, VARIABLE_2 instead of VARIABLE1, VARIABLE2, I suppose because it feels like the digits blend into the words without an underscore separating them. For a more real example see NUM2WORDS v NUM_2_WORDS, the latter seems far clearer, at least to me.
Is this "wrong" (as far as the definition of that word can stretch)? What is the prevailing style and why?
In prose (ordinary writing) you would write "variable 1" not "variable1", so for sake of consistency I think you should add an underscore when snake case is used, i.e. variable_1.
As the title says how would camel case, which is: theQuickBrownFox, work when one of the words starts with a lower case letter followed by a capital such as is the case in iPhone.
getiPhoneNumber() for instance looks weird.
Would it be getIphoneNumber() or getIPhoneNumber() or what?
what if it was the first word? iPhoneNumber vs iphoneNumber? Since only each different word should be capitalized.
Any algorithm that separates a camel case identifier back into individual words would correctly produce: get IPhone number from getIPhoneNumber and would be fooled by getiPhoneNumber because it would separate this into geti phone number. Therefore, the correct naming is getIPhoneNumber.
Using the very same criterion I would use iphoneNumber rather than iPhoneNumber.
EDIT
Given that there is some consensus about this question being opinion-based I would like to say that any criterion on how to capitalize a sentence using the camel case convention shouldn't be opinion based but consistent with whatever separation algorithm one would happen to use.
I know you can get a character vector of all numbers with ∊⍕¨⍳10, but is there a platform independent idiom for getting a vector of all alphabetical characters, aside from manually typing 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'? I know that I can do ⎕AV[(⍳26)+(⎕AV⍳'a')-1] to get all lowercase characters (and uppercase by changing the 'a' to 'A') in Dyalog APL, but I presume the system variable ⎕AV isn't available in other environments.
Not really.
In Dyalog APL, what I generally do is use ⎕A for the uppercase characters and ⎕UCS 96+⍳26 for the lowercase characters. (And ⎕A,⎕UCS 96+⍳26 for the whole alphabet.)
⎕AV is usually present, but its contents are not standard. (For example, NARS2000's ⎕AV is different from Dyalog's.) By the way, in Dyalog ⎕AV is considered deprecated in favour of ⎕UCS. Any APL that implements ⎕UCS will do it the same way, because Unicode is a set standard.
If you want a guaranteed implementation-independent, readable way to define the alphabet I would indeed recommend to just store abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ in your workspace.
However, I would not recommend trying to write implementation-independent APL code to begin with. APL dialects are rather divergent, so this is decidedly nontrivial (if possible at all for complex code), and will be difficult to maintain.
Even though Quad names (⎕xxx) are usually case insensitive, MicroAPL distinguishes between ⎕A and ⎕a, so ⎕a,⎕A gives 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'.
Yes, in the latest versions*, write ⎕A,819⌶⎕A, for ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.
Try it online!
Documentation.
* Latest builds of 14.1, and all versions of 15.0 and up.
Are there any other characters I can use in a <Say> verb to help the pronunciation (assuming I have too many options to just record them all as MP3s).
Thus far all I've found is hyphens to help with correctly detecting syllables:
Adgrok is pronounced "Addbrooke" but "Ad-grok" is pronounced correctly. "PagerDuty" is "pahdgerduty" but "pager-duty" is correct.
Capitals seem to be meaningless and spaces can introduce weirdness: "Mont Re Al." is pronounced "Mont Re Alabama"
Unfortunately, at this time there are no special punctuation marks that can help with pronunciation.
I use spaces and periods sometimes but other that that it can be hard when you are using trade names. Another trick is I wanted it to say mysite.com so i typed "mysite dot com" or spelling out numbers five for 5. I think a lot of it comes down to trial and error.
The standard for doing this is SSML (http://www.w3.org/TR/speech-synthesis/). While Twilio does not support this, Tropo does with their speech synthesis verb 'say'. So, you may do something like this:
answer
say "<speak> I like squirrels!.
I <prosody rate='-10%'>like squirrels!</prosody>
I <prosody rate='-30%'>like squirrels!</prosody>
I <prosody rate='-50%'>like squirrels!</prosody>
</speak>"
hangup
I set the culture to Hungarian language, and Chr() seems to be broken.
System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"
Chr(254)
This returns "ţ" when it should be "þ"
However, Asc("ţ") returns 116.
This: Asc(Chr(254)) returns 116.
Why would Asc() and Chr() be different?
I checked and the 'wide' functions do work correctly: ascw(chrw(254)) = 254
Chr(254) interprets the argument in a system dependent way, by looking at the System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage property. See the MSDN article about Chr. You can check whether that value is what you expect. "hu-US" (the hungarian locale as used in the US) might do something strange there.
As a side-note, Asc() has no promise about the used codepage in its current documentation (it was there until 3.0).
Generally I would stick to the unicode variants (ending on -W) if at all possible or use the Encoding class to explicitly specify the conversions.
My best guess is that your Windows tries to represent Chr(254)="ţ" as a combined letter, where the first letter is Chr(116)="t" and the second ("¸" or something like that) cannot be returned because Chr() only returns one letter.
Unicode text should not be handled character-by-character.
It sounds like you need to set the code page for the current thread -- the current culture shouldn't have any effect on Asc and Chr.
Both the Chr docs and the Asc docs have this line:
The returned character depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class. TextInfo.ANSICodePage can be obtained by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
I have seen several problems in VBA on the Mac where characters over 127 and some control characters are not treated properly.
This includes paragraph marks (especially in text copied from the internet or scanned), "¥", and "Ω".
They cannot always be searched for, cannot be used in file names - though they could in the past, and when tested, come up as another ascii number. I have had to write algorithms to change these when files open, as they often look like they are the right character, but then crash some of my macros when they act strangely. The character will look and act right when I save the file, but may be changed when it is reopened.
I will eventually try to switch to unicode, but I am not sure if that will help this issue.
This may not be the issue that you are observing, but I would not rule out isolated problems with certain characters like this. I have sent notes to MS about this in the past but have received no joy.
If you cannot find another solution and the character looks correct when you type it in, then I recommend using a macro snippet like the one below, which I run when updating tables. You of course have to setup theRange as the area you are looking at. A whole file can take a while.
For aChar = 1 To theRange.Characters.count
theRange.Characters(aChar).Select
If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
Next aChar