3 ms·
So here's a good test for the value of [language feature X]: Do people naturally try and reinvent that feature in its absence? So for named parameters you hav
by cletus 6y ago
So here's a good test for the value of [language feature X]:
Do people naturally try and reinvent that feature in its absence?
So for named parameters you have:
1. Javascript would often be written with methods with a single "options" parameter, where "options" is an anonymous object and basically a map;
2. Day-to-day I write Hack. Many functions are similarly written taking a shape as an argument. Shapes are structs, basically, but the typechecker is smart enough to treat them as a well-defined by anonymous type.
3. I've also seen C code that does much the same with things structs.
Empirically there seems to generally be a demand for this kind of feature and it makes sense: long parameter lists are tedious and error-prone (have you ever seen a function that has 3 boolean parameters in a row?) where people try and be helpful by providing "optional" parameters (which are really just parameters with default values).
So sure, I'm all for named parameters.
- noir_lord 6y agoThree? I found one in work codebase that had 9. That's 2^9 states to consider.
- hajile 6y agoJS records are superior. I can create an object, then dynamically add various parameters before sending them rather than bogging down the function call. Destructuring in particular ensures this is pleasant for both the function creator and consumer. You see a similar debate between StandardML and Ocaml though on a more fundamental level. SML uses structurally-typed records, so you can instantiate an inline record without needing to add any types and the function will destructure it for use. Ocaml went with nominal typing making this painful, so they added a complex optional argument syntax instead. Typescript is also structurally typed and I'd guess this is the reason.