Re: [File API] Draft for Review

On Thu, Jan 26, 2012 at 4:42 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Thu, Jan 26, 2012 at 6:25 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> As I argued in
>> <http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1520.html>,
>> we should absolutely *not* be adding more boolean arguments to the
>> platform.  They should be exposed as boolean properties in an
>> dictionary.
>
> I don't find this compelling; you could make the same argument for any
> optional argument.  When you only have a couple arguments, the additional
> verbosity is a loss, particularly if the argument is used frequently.
>
> When to use a dictionary is a judgement call, but it doesn't have anything
> to do with the argument's type.
>
>> Naked bools are impossible to decipher without memorizing the call
>> signature of every function.
>
> Unless you're going to argue that *all* optional arguments should be moved
> to dictionaries, this doesn't make sense--you always have to know the call
> signature of functions you're calling.  That's no burden as long as you
> don't have too many arguments (like init*Event).

That's not necessary.  There are situations when optional arguments
make sense.  They should be avoided, though, when you expect that
*future* optional arguments will have nothing to do with the current
one, as otherwise you'll have to specify the "optional" argument every
time with some null value.

Charles gives examples of a few arguments we may want to provide in
the future, all of which have nothing to do with whether the url is
single-use or reusable.

Ojan clarifies the "you have to memorize the call signature" argument
I was making - many arguments are pretty obvious and easy when you see
them in use.  Naked bools almost never are.

~TJ

Received on Friday, 27 January 2012 01:02:38 UTC