- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 27 Jan 2012 09:04:04 -0800
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Mike Taylor <miket@opera.com>, Arun Ranganathan <aranganathan@mozilla.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
On Fri, Jan 27, 2012 at 5:59 AM, Glenn Maynard <glenn@zewt.org> wrote:
> On Thu, Jan 26, 2012 at 11:09 PM, Mike Taylor <miket@opera.com> wrote:
>>
>> Yes, synthetic keypress have multiple problems--which is why we all use
>> libraries to not have to author them by hand.
>>
>> Regardless, this doesn't change the fact that
>> window.URL.createObjectURL(file, true) is more opaque (and for me, harder to
>> remember) than:
>>
>> window.URL.createObjectURL(file, {oneTimeOnly: true})
>>
>> or something magical like window.URL.createObjectURL(file).oneTimeOnly()
>
>
> Again, this argument is fine, but has nothing to do with booleans. The
> same argument could be made for URL.createObjectURL(file, {expireInSeconds:
> 1000}) vs. URL.createObjectURL(file, 1000), or any other optional parameter.
...yes? It can be. I made the general argument above - if an
optional argument has *no relation* to expected future optional
arguments, then it shouldn't be an optional argument at all, it should
be a keyword argument instead (implemented in JS via a dictionary
object arg). Otherwise authors will end up being forced to specify
the "optional" argument with a dummy value just because they actually
want to specify a later optional argument.
You should only create multiple optional arguments when specifying a
later one *implies* that the earlier ones should be specified as well.
You shouldn't create a *single* optional argument if you expect that
it won't have such a relationship with things made in the future.
~TJ
Received on Friday, 27 January 2012 17:05:13 UTC