- From: <bugzilla@jessica.w3.org>
- Date: Thu, 09 Jan 2014 04:36:02 +0000
- To: public-script-coord@w3.org
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