Hi
On 4/7/24 06:37, Juliette Reinders Folmer wrote:
I forwarded your questions from above verbatim to Nicolas and this was
his response (also quoted verbatim):
Thank you.
So, this one is interesting.
Sure, if you look at these extremes, stringing them back to back all
in a uppercase, they are not particularly user-friendly to read.
Then again, none of these solutions are super user-friendly. We are
dealing with making the best of things.
I have to say, it always gets my goat a little bit when people raise
“the extremes” in the context of accessibility. Somehow it always ends
up feeling like, to me at least, like a copout.
Like, sure if you have someone who is blind, deaf, and paralyzed from
a stroke, making something accessible to them is going to be extremely
difficult. It doesn’t mean you shouldn’t make things accessible to
people who are blind, to people who are deaf, and to people who are
paralyzed from a stroke.
This is a little bit like that. The solution I proposed earlier may
not work for everybody. But it will work for a majority.
While I've called the examples “extreme” myself, I don't believe they are *uncommon*. Programming is full of various acronyms and it naturally follows that some identifiers will consist of consecutive acronyms or abbreviations. I've mentioned five of them in my previous email, but added some more to the RFC as part of Saki's namespace question (SSL + CRL + URL).
Here are some more acronyms that are reasonable to appear within in a single identifier. Some of them might make sense to put in a namespace hierarchy which comes with the backslash as a separator, but this does not work for method names:
ASN.1 + DER
AES + GCM
JWT + RSA
HMAC + SHA-256
API + Anything probably
SAML + SSO
GPU + CUDA
ARM + CPU
Apologize the focus on cryptographic concepts, but these case to my mind most easily :-)
Best regards
Tim Düsterhus