I could have sworn this came up previously. What are ppl's thoughts on this state of affairs: https://trycf.com/gist/aa08c8e3eae08360b6efc2149c8cb84d/acf2021?theme=monokai (CF 2021 only)

s = "abc"
s.each((c)=>{
    //writeoutput(c.ucase()) // The ucase method was not found
    writeOutput("#c.getClass().getName()#<br>") // java.lang.Character
    writeOutput("#c.toString().ucase()#<br>") // sigh
})
writeOutput("<hr>")
a = s.split("")
c = a[1]
writeOutput("#c.ucase()#: #c.getClass().getName()#<br>") // A: java.lang.String

When using CF2021's string iteration functions, each element of the string is a

java.lang.Character

, not a

java.lang.String

. Ramifications: one cannot call string member functions on the char (obvs), eg:

c.ucase()

. I say "obviously" because a Character is not a String, however it's NOT obvious in the context of CFML because Character is not a CFML data type, so there's no way a CFML function should return one / pass one. I include as an example there that even Java doesn't split a string into individual Character objects. They're Strings. I could not find a bug for this in the bugbase. @Mark Takata (Adobe) just... why?

Can't say I've seen that one. I would certainly expect them to be proper strings.

(ref: https://helpx.adobe.com/coldfusion/cfml-reference/new-changed-functions-coldfusion-2021.html)

You have extremely niche middle of the night on a Friday hobbies mate. But you're not wrong, that's a bad implementation (I'm being kind). I'll log it.

Not sure you needed "middle of the night on a Friday" in that sentence, but to each their own.

Not that anyone is likely to care, CFML's behavior matches Clojure's

user=> (map class "abc")
(java.lang.Character java.lang.Character java.lang.Character)
user=> (map class (.split "abc" ""))
(java.lang.String java.lang.String java.lang.String)
user=>

Interesting. I think a difference here is that given Clojure is a "proper" JVM language, it "knows" what a java.lang.Character is. There isn't a Character data-type in native CML, so I stand by my position that it's invalid for CF to expose Characters to CFML code like this. It is worth noting that the

ucase

function accepts Characters just fine (ie: change my example code to be

ucase(c)

rather than

c.ucase()

"the

ucase

function accepts Characters" given the docs say it accepts a string and doesn't mention accepting characters, I'd even lean towards saying "serendipitously happens to not blow up when passed Characters". If a minor update were to change it to blow up when passing a java Character object instead of a string, and there were no release notes on it, I'd not bat an eye.

The latter is the key here.