It’s not a string argument though, it’s JS. You can argue it’s expected to be a string but like the rest of JS all you can know from the signature alone is that it takes an object. Hopefully your little ducky quacks the right way!
JavaScript doesn’t have typed parameters or variables. The function expects a string and does things in the function body which converts the object into a string. JS shares this behavior with all dynamically typed languages and it’s extremely useful in some contexts and extremely frustrating in others. It’s down to what it’s being used for. Dynamic languages make excellent scripting languages, see Python really just being a souped up shell lang
The function expects a string and does things in the function body which converts the object into a string.
… These are different words that describe exactly what I’m saying. I’m saying: in the place where there should be a string argument, because the function expects one, there is not a string argument, but a number argument. (Not an object like you keep saying.)
I know all that stuff about dynamically typed languages. I’m just saying that the function is being used indirectly here.
You cannot have a string argument, arguments and variables in JS don’t have a type. All you have in JS is objects. Actual functions, like full on function foo(){}are still objects, like you can actually store data on the things.
Where are you getting these typeless function signatures? You should get them from somewhere else.
The Ecmascript Spec for parseInt doesn’t have a type listed for the first argument, but it does call the argument “string,” which should be a pretty clear hint that it’s expected to be a string. It also explicitly states that the first step of parseInt is to coerce the first argument to a string. You should view older versions of the spec to see how it performs in older browsers / runtimes.
The MDN entry for parseInt makes it clear that parseInt expects a string or a string and explicit radix (i.e., 10 for base 10/decimal, or 16 for hexadecimal). MDN is what I recommend anyone who’s writing JavaScript use as their first resource for core JS features, for what that’s worth.
I use WebStorm to write JavaScript (and more frequently, TypeScript), and if I type parseInt( and pause a second, it pops up a type hint that reads string: string, radix?: number.
I checked in VSCode, too, and it pops up this:
parseInt(string: string, radix?: number | undefined): number`
A string to convert into a number.
Converts a string to an integer.
You can set something similar up with an LSP in Vim or Neovim, and presumably in Emacs as well.
You have argued that it’s expected to be a string congrats. You’ll notice from the grammer you used that there isn’t an actual type here, you specifically pointed out how your IDE displays a type hint which is only slightly better than somebody writing some form of documentation on what the type is. Dynamic languages don’t have typed args, least none that I’ve heard of.
It’s not a string argument though, it’s JS. You can argue it’s expected to be a string but like the rest of JS all you can know from the signature alone is that it takes an object. Hopefully your little ducky quacks the right way!
Huh? The code in the image is passing a number argument where there should be a string argument.
And this function is specifically made to parse a string into an int. Apply common sense.
JavaScript doesn’t have typed parameters or variables. The function expects a string and does things in the function body which converts the object into a string. JS shares this behavior with all dynamically typed languages and it’s extremely useful in some contexts and extremely frustrating in others. It’s down to what it’s being used for. Dynamic languages make excellent scripting languages, see Python really just being a souped up shell lang
… These are different words that describe exactly what I’m saying. I’m saying: in the place where there should be a string argument, because the function expects one, there is not a string argument, but a number argument. (Not an object like you keep saying.)
I know all that stuff about dynamically typed languages. I’m just saying that the function is being used indirectly here.
You cannot have a string argument, arguments and variables in JS don’t have a type. All you have in JS is objects. Actual functions, like full on
function foo(){}are still objects, like you can actually store data on the things.Where are you getting these typeless function signatures? You should get them from somewhere else.
The Ecmascript Spec for parseInt doesn’t have a type listed for the first argument, but it does call the argument “string,” which should be a pretty clear hint that it’s expected to be a string. It also explicitly states that the first step of parseInt is to coerce the first argument to a string. You should view older versions of the spec to see how it performs in older browsers / runtimes.
The MDN entry for parseInt makes it clear that
parseIntexpects a string or a string and explicit radix (i.e., 10 for base 10/decimal, or 16 for hexadecimal). MDN is what I recommend anyone who’s writing JavaScript use as their first resource for core JS features, for what that’s worth.I use WebStorm to write JavaScript (and more frequently, TypeScript), and if I type
parseInt(and pause a second, it pops up a type hint that readsstring: string, radix?: number.I checked in VSCode, too, and it pops up this:
You can set something similar up with an LSP in Vim or Neovim, and presumably in Emacs as well.
You have argued that it’s expected to be a string congrats. You’ll notice from the grammer you used that there isn’t an actual type here, you specifically pointed out how your IDE displays a type hint which is only slightly better than somebody writing some form of documentation on what the type is. Dynamic languages don’t have typed args, least none that I’ve heard of.