[Bug 24241] Adopt the ES6 "safe integer" range for (unsigned) long longs

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24241

--- Comment #5 from Marcos Caceres <w3c@marcosc.com> ---
(In reply to Boris Zbarsky from comment #3)
> Marcos, what is the goal of getting rid of numeric types?

I'm not suggesting we get rid of the types (as some have a legacy purpose in
DOM/HTML, like "long" in various places - though even there the use is highly
suspect) - I'm suggesting we make a new type and discourage the use of the
other types unless there is a really good reason to do so (as it's already done
for various things in WebIDL). A lot of the time, people just need some
argument to be coerced into a signed or unsigned number - or need a readonly
attribute that returns a number when gotten.

As Domenic suggests, I guess we would need to look at what predefined ranges
specs use (and why).

> They were added because various specifications wanted to coerce numbers to
> integers in some range, and having everyone reinvent the wheel for how to do
> that is pretty suboptimal....

I thought this was mostly a carry over from OMGIDL from the DOM1 days and for
compatibility with Java. But yes, reinventing the wheel would not be fun.
However, a more flexible range mechanism (as Domenic suggested in #4 and as
I've suggested to Cam in the past also) would make more sense - specially for
the silly types like Octet, Byte, Short, etc. which are just range enforcers
that are masquerading as types.  

>  now you may argue that people shouldn't be
> coercing numbers to integers, but it turns out to be necessary when you need
> to talk to platform (like operating system, outside the browser) APIs or
> whatnot.  And then we need to define the exact coercion steps.

Right, but this is the exception - not the rule AFAICT. As Domenic suggests, we
would probably need to check what's actually used in the platform and what
value each type actually brings. 

> As for EnforceRange, it was added so that specifications that want to throw
> on out of range input instead of the somewhat asinine default modulo
> behavior (which was left for backwards compat) don't have to reimplement
> coercion to a narrower integer type from scratch.  And it's used by at least
> IndexedDB and the Media Source Extensions APIs.

We should check if the uses there are actually valid/necessary or if there is a
better solution (or something that a new type could give you for free).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 9 January 2014 04:36:11 UTC