Date: Mon, 08 Jul 2019 15:56:51 +0000
On Monday, July 8, 2019 6:40 AM, Barry Revzin via Std-Proposals <std-proposals_at_[hidden]> wrote:
> The thing is, when you have named parameters, you can just write one function that takes 30 parameters. And that can be a great API. How many parameters can maplotlib.pyplot.plot() take? Probably hundreds. And some parameters even have long and short names (e.g. linewidth and lw)! That's not lazy and it's certainly not unusable - on the contrary, it's one of the most usable and useful libraries I've ever used.
Yes! Every time when people talk about
this topic, the argument claiming "named
arguments can lead to bad design because
APIs with many parameters are bad design"
will be raised. TBO, they sound like
"commands with lots of command-line
options are a bad design."
PS: on alternative names such as `linewidth`
and `lw`, designated initializer has a way to
express it:
struct __generated {
...
union {
double linewidth, lw;
};
};
> The thing is, when you have named parameters, you can just write one function that takes 30 parameters. And that can be a great API. How many parameters can maplotlib.pyplot.plot() take? Probably hundreds. And some parameters even have long and short names (e.g. linewidth and lw)! That's not lazy and it's certainly not unusable - on the contrary, it's one of the most usable and useful libraries I've ever used.
Yes! Every time when people talk about
this topic, the argument claiming "named
arguments can lead to bad design because
APIs with many parameters are bad design"
will be raised. TBO, they sound like
"commands with lots of command-line
options are a bad design."
PS: on alternative names such as `linewidth`
and `lw`, designated initializer has a way to
express it:
struct __generated {
...
union {
double linewidth, lw;
};
};
-- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________
Received on 2019-07-08 10:58:51