3 ms·

> let website = new String("BaseClass") > website.rating = "great!" Ok that’s new to me. Can anyone point out where this could be useful, if anywhere?

greggturkington 6y ago
Primarily for adding properties, and making objects that can be inherited from (unlike primitives). This is a great answer with even more cases: https://stackoverflow.com/a/39113022/110241 https://stackoverflow.com/a/39113022/110241
- mgerullis 6y ago
  > Primarily for adding properties I personally would never expect a property which is treated as a string. That's what POJOs are for, but that is just opinion I guess. still weird they let you do this. > and making objects that can be inherited from (unlike primitives). I mean the SO gives an example of how to do it but I would still love to see some place where this is needed or even pragmatic to any degree.
Ciantic 6y ago
Only thing useful I can come up is monkey patching without changing the function signature. E.g. smuggling additional data to a function which expects a string like thing. But I think the whole `new String` is problematic, because it breaks the strict comparison: let a = "Foo"; let b = new String("Foo"); a === "Foo" true b === "Foo" false
- mgerullis 6y ago
  > Only thing useful I can come up is monkey patching without changing the function signature. E.g. smuggling additional data to a function which expects a string like thing. Yeah this sounds terrifying to me, if I were to debug something like this. Also the fact they identify as objects: typeof new String("Foo") === 'object'; Case closed, I will never use it :D
eyelidlessness 5y ago
It’s useful to know about even if you have no use case for it. Because this conversion happens every time you access a property on any JS primitive. For example, this: str.toUpperCase() Is actually doing this: new String(str).toUpperCase() ...hand waving away obvious optimizations that surely occur for multiple property access. There may be cases, for instance a series of imperative synchronous hot loops, where this has a meaningful performance impact. Another thing that’s important to know is that you can do this: Object.assign(str, { anythingAt: ‘all’ }) And you’ve now mutated your string into a String. This breaks a buuuuunch of expected behaviors with primitives, such as === and the default Array#sort comparator. Edit: this last one bit me experimenting with a runtime implementation of a common pattern in TypeScript to define nominal types for primitives (e.g. to distinguish a known valid URL from a regular string) called branding[1]. The approach is useful if you’re obsessive about type safety, but flawed because it almost certainly misrepresents the runtime type. I tried to use Object.assign to get that much more type safety and... I got the opposite! I got a String claiming to be a string, which broke all sorts of stuff, including the aforementioned === and Array#sort. 1: https://medium.com/@KevinBGreene/surviving-the-typescript-ecosystem-branding-and-type-tagging-6cf6e516523d https://medium.com/@KevinBGreene/surviving-the-typescript-ec...

greggturkington 6y ago

Primarily for adding properties, and making objects that can be inherited from (unlike primitives). This is a great answer with even more cases: https://stackoverflow.com/a/39113022/110241 https://stackoverflow.com/a/39113022/110241

mgerullis 6y ago
> Primarily for adding properties I personally would never expect a property which is treated as a string. That's what POJOs are for, but that is just opinion I guess. still weird they let you do this. > and making objects that can be inherited from (unlike primitives). I mean the SO gives an example of how to do it but I would still love to see some place where this is needed or even pragmatic to any degree.

Ciantic 6y ago

Only thing useful I can come up is monkey patching without changing the function signature. E.g. smuggling additional data to a function which expects a string like thing. But I think the whole `new String` is problematic, because it breaks the strict comparison: let a = "Foo"; let b = new String("Foo"); a === "Foo" true b === "Foo" false

mgerullis 6y ago
> Only thing useful I can come up is monkey patching without changing the function signature. E.g. smuggling additional data to a function which expects a string like thing. Yeah this sounds terrifying to me, if I were to debug something like this. Also the fact they identify as objects: typeof new String("Foo") === 'object'; Case closed, I will never use it :D

eyelidlessness 5y ago

It’s useful to know about even if you have no use case for it. Because this conversion happens every time you access a property on any JS primitive. For example, this: str.toUpperCase() Is actually doing this: new String(str).toUpperCase() ...hand waving away obvious optimizations that surely occur for multiple property access. There may be cases, for instance a series of imperative synchronous hot loops, where this has a meaningful performance impact. Another thing that’s important to know is that you can do this: Object.assign(str, { anythingAt: ‘all’ }) And you’ve now mutated your string into a String. This breaks a buuuuunch of expected behaviors with primitives, such as === and the default Array#sort comparator. Edit: this last one bit me experimenting with a runtime implementation of a common pattern in TypeScript to define nominal types for primitives (e.g. to distinguish a known valid URL from a regular string) called branding[1]. The approach is useful if you’re obsessive about type safety, but flawed because it almost certainly misrepresents the runtime type. I tried to use Object.assign to get that much more type safety and... I got the opposite! I got a String claiming to be a string, which broke all sorts of stuff, including the aforementioned === and Array#sort. 1: https://medium.com/@KevinBGreene/surviving-the-typescript-ecosystem-branding-and-type-tagging-6cf6e516523d https://medium.com/@KevinBGreene/surviving-the-typescript-ec...