- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 24 Sep 2012 12:15:36 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHATWG List <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Mon, Sep 24, 2012 at 11:51 AM, Ian Hickson <ian@hixie.ch> wrote: > On Sun, 23 Sep 2012, Tab Atkins Jr. wrote: >> On Sun, Sep 23, 2012 at 3:57 PM, Ian Hickson <ian@hixie.ch> wrote: >> > On Fri, 21 Sep 2012, Tab Atkins Jr. wrote: >> >> So, can we rename the 7-arg arcTo to ellipseTo? That seems to >> >> support your "always [require] all the arguments" recommendation. ^_^ >> > >> > Just have one arcTo command, that takes all the arguments. Why split >> > it into two, if you always require all the arguments? >> >> Oh, that's what you meant. >> >> That seems silly. It's more convenient and simple for authors to have a >> circular form, separate from the elliptical form. It lets you omit the >> second radius and the rotation, as they're irrelevant. > > Omitting two numbers, one of which is zero, is easily no more a win than > the cost of having two different nearly-identical commands. Just consider > C/c and S/s; is it really worth it? I'm not at all convinced that that's true. Sure, it is fewer number of functions to document and fewer number of functions for people to learn. But that obviously isn't the only metric that we care about since then we'd just cram all functionality into a single function with a huge number of optional arguments. Optional arguments, especially once that make a function behave very different, makes code harder to read. It also means that people have to put more complexity into their heads as they have to remember which number of arguments gives what behavior. All in all I generally try to avoid optional arguments except when their behavior is very obvious. Using dictionaries help a bunch since they add documentation right in the code of what the purpose is for each optional argument. / Jonas
Received on Monday, 24 September 2012 19:16:33 UTC