Re: [heycam/webidl] Should EnforceRange be allowed on consts and return types? (#842)

> Can't you pass the same object where different WebIDL dictionary types are required, for example?

If you made multiple dictionaries with the exact same members, then yes, I agree that would be just as misleading and against the grain of Web IDL.

> My understanding is that WebIDL spec defines what is expected in objects passed by the user. It can't enforce what these things are, since JS is weakly and dynamically typed

I wouldn't really put it that way. In particular, Web IDL defines, and allows specs to define, conversion rules for how to turn JavaScript values into Web IDL values. Having, e.g., different dictionary types (which generate different conversion rules), or different integer types (e.g. `long` vs. `unsigned long`, which generate different conversion rules), is helpful.

But if you define two _exact same conversion rules_ under different names, that's generally confusing for readers, causing them to dig through your indirection to realize what conversion rules are actually in place. Sometimes there's a brevity benefit, especially around typedefing large unions or deeply-nested generic structures, which outweighs this confusion; that's generally why typdefs exist. But they don't exist so that you can express "perform ToNumber, round to an integer, and take the value modulo 2\*\*32" in several different ways. We have a canonical way to do that, namely `unsigned long`.

To be clear, I'm _not_ saying that we should disallow typedefing primitives, or other "simple" types, in the Web IDL spec. Where to use typdefs, and make the indirection tradeoff, is a choice that individual specification editors should make. Instead, I'm just explaining why when you attempt to use them in this way, you'll run into issues like the ones discussed in this thread.

-- 
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/842#issuecomment-668279479

Received on Monday, 3 August 2020 22:54:15 UTC