- Then “b” backwards would have to be “d” - "E".reverse() == "∃"
 
- “:-)”.reverse() == “)-:” - Close enough 
- The npm package - flip-textis the closest that I know of:- const flip = require('flip-text'); const str = "dobo"; const flippedStr = flip(str); console.log(flippedStr); // Output: "qoqo"- However, with great libraries like is-thirteen I’m sure JavaScript will some day gain a proper flipping library. 
- You could implement that on a chat, but I wouldn’t do that on a string - Where’s your sense of adventure?! 
 
- Be the operator overload you wish to see in the world 
- JavaScript taking notes 
- but - "🙂".reverse() == "🙃"
- "☹️".reverse() == "☹️"- You’re no fun - Look closer at the beauty mark, I flipped the emoji 
 
- wasn’t it 
 🙁
 .
 r
 e
 v
 e
 r
 s
 e
 ()- " 
 🙂
 "
 .
 r
 e
 v
 e
 r
 s
 e
 (
 )
 =
 "
 🙃
 "
 
 
- "🐈".concat() = "😼"
- Also, it should turn an error into an empty but successful call. /s - Calling - reverse()on a function should return its inverse- isprime.reverse(True) // outputs 19 billion prime numbers. Checkmate, atheists.- It’s a just a joke, but I feel like that actually says something pretty profound about duck typing, and how computable it actually is. 
 
 
 
- Today I found out that this is valid JS: - const someString = "test string"; console.log(someString.toString());- I dint know many OO languages that don’t have a useless - toStringon string types. It mostly seems to be a result of using a generic string-able type that’s implemented to add toString() in a standardised way.- Calling - toStringon a string is practically a no-op anyway.- I dint know many OO languages that don’t have a useless toString on string types - Okay, fair enough. Guess I never found about it because I never had to do it… JS also allows for - "test string".toString()directly, not sure how it goes in other languages.- Java would be - "test string".toString(). C# has- "test string".ToString(). Python has- str("test string")(as- str()is Python’s- toStringequivalent). Rust has- String::from("test string").to_string().- That’s just from the top of my head. I’m sure there’s more. - Edit: actually, I think Rust’s - to_string()may not be entirely useless, I think it may be used as a consuming placeholder for- clone()? Not sure how that would be useful, but it’s not a complete no-op at least.
- It’s also incredibly useful as a failsafe in a helper method where you need the argument to be a string but someone might pass in something that is sort of a string. Lets you be a little more flexible in how your method gets called 
 
- I dint know many OO languages that don’t have a useless toString on string types. - Well, that’s just going to be one of those “it is what it is” things in an OO language if your base class has a - toString()-equivalent. Sure, it’s probably useless for a string, but if everything’s an object and inherits from some top-level- Objectclass with a- toString()method, then you’re going to get a- toString()method in strings too. You’re going to get a- toString()in everything; in JS even functions have a- toString()(the output of which depends on the implementation): - In a dynamically typed language, if you know that everything can be turned into a string with - toString()(or the like), then you can just call that method on any value you have and not have to worry about whether it’ll hurl at runtime because eg.- Strings don’t have a- toStringbecause it’d technically be useless.- Same is true for JavaScript’s namesake, Java; - Objecthas a- toStringmethod, so everything but primitives (- int,- long, etc.) must have a- toStringmethod (and primitives sort of have one too in a roundabout way).- I think JavaScript’s - toStringalso serves another function, namely to have some form of fallback when doing operations on what should be incompatible types.- [] + "", for instance; JavaScript will call- toString()to do type conversion when the nearest matching type is a- String.
 
 
 - Everything that’s an - Objectis going to either inherit- Object.prototype.toString()(mdn) or provide its own implementation.- A - Stringis an- Object, so it’s going to have a- toString()method. It doesn’t inherit- Object’s implementation, but provides one that’s sort of a no-op / identity function but not quite.- So, the thing is that when you say - const someString = "test string", you’re not actually creating a new- Stringobject instance and assigning it to- someString, you’re creating a- string(lowercase- s!) primitive and assigning it to- someString: - Compare this with creating a - new String("bla"): - In Javascript, primitives don’t actually have any properties or methods, so when you call - someString.toString()(or call any other method or access any property on- someString), what happens is that- someStringis coerced into a- Stringinstance, and then- toString()is called on that. Essentially it’s like going- new String(someString).toString().- Now, what - String.prototype.toString()(mdn) does is it returns the underlying- stringprimitive and not the- Stringinstance itself.- Why? Fuckin beats me, I honestly can’t remember what the point of this is because I haven’t been elbow-deep in Javascript in years, but regardless this is the logic behind - String’s- toString().
 
- [🌽].pop() == 🍿- 🚴.push() = 🚲🤸
 
- Best I can do is - "\ude41🙂".split("").reverse().join("")- returns - "\ude42🙁"








