Re:JavaScript Coercions Grid
by shawnz on Saturday March 30, 2019 @10:59AM
(#19529722)
Agreed, These corner cases are weird only because there's basically no sensible thing to do in these situations which would be consistent with the rest of the rules. Since there's no real reason you'd be doing any of these weird coersions I think it's pretty unlikely that they'd result in bugs. It's not fail-fast, but I don't see this stuff resulting in any subtly incorrect behaviors.
[ Parent
| on HN ]
Re:JavaScript Coercions Grid
by ficklepickle on Saturday March 30, 2019 @02:09PM
(#19530825)
What about calling toString() on an object? I think serializing the object would be more useful than [object Object].
I'm sure JSON.stringify didn't exist originally, so it wasn't an option. I guess it must be for backwards compatibility, but I can't think of much of a use case. Maybe something somewhere uses it instead of typeof?
Re:JavaScript Coercions Grid
by seanwilson on Saturday March 30, 2019 @11:31AM
(#19529898)
> there's basically no sensible thing to do in these situations
Are there any better options for dynamic languages when a weird coercion is going to be done? Throw an exception? Exit with an error? Convert to some special invalid_coercion value similar to NaN?
It's another reason static type checking (i.e. don't let the code run) is a no-brainer to me.
>Throw an exception?
Seems like the best choice rather than plowing ahead with assumptions
Re:JavaScript Coercions Grid
by jimmaswell on Saturday March 30, 2019 @01:12PM
(#19530534)
I feel like it's fine for languages in a web context to take a "the show must go on" attitude as they do. Partially working webpages (slightly broken html/js/etc) are generally much better than a blank page/error message or none of the js working at all.
Dynamic languages are all about letting the caller decide what makes sense and what doesn't, rather than the callee. If you are too conservative with the input types you allow then it can create unnecessary coupling.