I understand that, if the ECMAScript specification favors trimStart() over trimLeft() and trimEnd() over trimRight(), then that's probably the standard we should follow. But I actually wonder if the standards committee might've been a bit shortsighted in their recommendations? Consider this example:
constmyArabicString=' ثعلب بني سريع ';console.log(myArabicString.trimLeft());console.log(myArabicString.trimStart());
Of course, both console.log() functions do the same thing. And if we use trimLeft(), I'm pretty certain that anyone reading the code would understand that we are trimming the space to the left of سريع. As far as I know, "left" and "right" are fairly universal ideas.
But if we use trimStart(), this strikes me as a potential source of confusion in a non-Anglo-centric world. The Arabic language - like a number of others - is read from right to left. And the "starting location" is relative to your own point of reference. So it's reasonable to think that an Arabic-speaking coder might look at the second console.log() and make the mistake of assuming that it will actually trim the space on the right side of the string. Because, if you're reading Arabic text, the right side of the string is the "start" of the string.
Oh! i wasn't aware of that! Thanks for sharing your insight. Hmm...I do wonder how they came up with this and if anyone brought this to their attention during the proposal stage. Looking at the proposal at github, it doesn't seem like there were any 🤔 github.com/tc39/proposal-string-le...
But start is not from start of text, is from start of string and string starts always at position 0 from left. Is not related with string as localized language, is related with string as an element of javascript language.
Yeah, I get that. And I'm not trying to imply that trimStart() is, in any way, "wrong". But we have two arbitrary names that could be used to describe the function. One of those names is universal - i.e., "left" is "left", everywhere. The other name is not universal. It forces you to think in terms of an "element of JavaScript", even though strings are very often associated with natural language and "start" and "end" mean different things, depending upon the natural language we're using. The standards group chose to recommend the meaning that is not universal. Hmm...
I'm not claiming it's any kinda huge tragedy. It would rarely cause anyone even the slightest of confusion. If you're a left-to-right native speaker like me (and most of us are), you'll probably never even think about the tiny little ambiguity. I just think that, if they'd thought that one through, they would have chosen the naming convention that is unambiguous.
There are only two hard things in computer science: cache invalidation and naming things. - Phil Karlton
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I understand that, if the ECMAScript specification favors
trimStart()overtrimLeft()andtrimEnd()overtrimRight(), then that's probably the standard we should follow. But I actually wonder if the standards committee might've been a bit shortsighted in their recommendations? Consider this example:Of course, both
console.log()functions do the same thing. And if we usetrimLeft(), I'm pretty certain that anyone reading the code would understand that we are trimming the space to the left of سريع. As far as I know, "left" and "right" are fairly universal ideas.But if we use
trimStart(), this strikes me as a potential source of confusion in a non-Anglo-centric world. The Arabic language - like a number of others - is read from right to left. And the "starting location" is relative to your own point of reference. So it's reasonable to think that an Arabic-speaking coder might look at the secondconsole.log()and make the mistake of assuming that it will actually trim the space on the right side of the string. Because, if you're reading Arabic text, the right side of the string is the "start" of the string.Oh! i wasn't aware of that! Thanks for sharing your insight. Hmm...I do wonder how they came up with this and if anyone brought this to their attention during the proposal stage. Looking at the proposal at github, it doesn't seem like there were any 🤔 github.com/tc39/proposal-string-le...
But
startis notfrom start of text, isfrom start of stringandstringstarts always at position0from left. Is not related with string as localized language, is related with string as an element of javascript language.Yeah, I get that. And I'm not trying to imply that
trimStart()is, in any way, "wrong". But we have two arbitrary names that could be used to describe the function. One of those names is universal - i.e., "left" is "left", everywhere. The other name is not universal. It forces you to think in terms of an "element of JavaScript", even though strings are very often associated with natural language and "start" and "end" mean different things, depending upon the natural language we're using. The standards group chose to recommend the meaning that is not universal. Hmm...I'm not claiming it's any kinda huge tragedy. It would rarely cause anyone even the slightest of confusion. If you're a left-to-right native speaker like me (and most of us are), you'll probably never even think about the tiny little ambiguity. I just think that, if they'd thought that one through, they would have chosen the naming convention that is unambiguous.