Re: [heycam/webidl] A non-optional dictionary argument makes sense at times. (#130)

> I think the issue is that we don't have any good tools in the JavaScript toolbox for expressing the requirement "please fill out at least one of these values". Speaking very generally, you're supposed to use parameters for required values, and dictionaries for optional values. But the use case presented here is neither of those.

I really don't understand this. Nowhere in WebIDL can I see any indication of this philosophy. It just says "A dictionary is a definition ... used to define an ordered map data type with a fixed, ordered set of entries, termed dictionary members." It goes on to say "One use of dictionary types is to allow a number of optional arguments to an operation without being constrained as to the order they are specified at the call site." I don't see it being a "weird fit" to have a dictionary with optional fields but at least one of them is required. That's really just an additional constraint; as programmers / API designers we can always add extra constraints to function inputs that can't be expressed declaratively by the programming language's data type syntax.

I feel like this rule makes about as much sense as saying that all integer arguments must be optional, because omitting them should be the same as passing 0. Now I write a method with an int argument that must be non-zero, and in the method I check it and throw a TypeError if it's <= 0. You tell me I *must* declare that argument as "optional" even though it will always be a TypeError to omit it. I say "but it must be explicitly supplied a non-zero value" and you tell me that it's a "weird fit for the int type" and I "shouldn't be using int, because that's not what int was originally designed for (even though we don't have a data type for non-zero int)".

I *do* buy the argument that we want to enforce this rule at some level (e.g., in Firefox's IDL parser, idlharness tests, etc) and I think it's okay to acknowledge that we're going to mandate "optional" even where it doesn't make sense in order that the common case be enforced. (I disagree that this is so important, but if that's the reason then I'll shut up and go along with it, but then I think Web IDL should acknowledge this friction and explain that it's enforced for pragmatic reasons.) It's just not satisfactory to say "you're holding it wrong" to people who are writing specs with this type of requirement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/130#issuecomment-313603328