Last Comment Bug 631132 - Expose public APIs for converting doubles to signed/unsigned int per ECMA spec
: Expose public APIs for converting doubles to signed/unsigned int per ECMA spec
: dev-doc-complete
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Andreas Gal :gal
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: 630052
  Show dependency treegraph
Reported: 2011-02-02 20:28 PST by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2011-04-21 10:27 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (1.37 KB, patch)
2011-02-02 20:32 PST, Andreas Gal :gal
bzbarsky: review+
Details | Diff | Splinter Review

Description Boris Zbarsky [:bz] (still a bit busy) 2011-02-02 20:28:27 PST
Could be useful in places where we have to write bindings.
Comment 1 Andreas Gal :gal 2011-02-02 20:32:22 PST
Created attachment 509339 [details] [diff] [review]
Comment 2 Andreas Gal :gal 2011-02-02 20:34:00 PST
NPOTB, not currently in use.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-02-02 20:38:39 PST
Comment on attachment 509339 [details] [diff] [review]

Land it.
Comment 4 Brendan Eich [:brendan] 2011-02-02 22:32:12 PST
Comment on attachment 509339 [details] [diff] [review]

Does it not seem confusing to have the old JS_ValueToInt32, which rounds to nearest and fails if the double is out of range, the newer but still ancient JS_ValueToECMA{I,Ui}nt32 pair, and now these JS_DoubleTo{I,Ui}nt32 which match ECMA-262 and do not match JS_ValueToInt32?

We could rotate names to give the old, pre-ECMA JS_ValueToInt32 a long and better name, giving the ECMA names the short and "ECMA"-free names. We could mangle the names of the JS_DoubleTo{I,Ui}nt32 APIs to contain "ECMA". But just adding more mixed naming does not seem good. Right?

Comment 5 Jeff Walden [:Waldo] (remove +bmo to email) 2011-02-03 01:41:16 PST
Hyperbole for sure, but rotating names feels somewhat like rearranging deck chairs to me.  The names certainly aren't pretty, but name stability seems to trump aesthetics to me, as far as external APIs go.  (Although fixing bugs/enabling better features itself trumps stability, cf. operation callback breakages and so on.)  If we want to regularize names, it seems most sensible to do that as part of JSAPI2.
Comment 6 Brendan Eich [:brendan] 2011-02-03 10:36:48 PST
Agree with comment 5, which leaves adding "ECMA" to the parallel DoubleTo names. Agreed?

Comment 7 :Ms2ger (⌚ UTC+1/+2) 2011-03-25 14:09:51 PDT
This is blocking some of my work. Any chance this could be landed soonish?
Comment 8 Andreas Gal :gal 2011-03-29 19:22:14 PDT
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-03-29 19:23:47 PDT
What about comment 4 through comment 6?
Comment 10 Jeff Walden [:Waldo] (remove +bmo to email) 2011-03-29 19:55:57 PDT
Pre-landing I'm willing to care about names (or not care, as my previous comment seems to say).  Post-landing, whatever got landed is good enough, since naming consistency is basically impossible until JSAPI2.
Comment 11 Andreas Gal :gal 2011-03-29 21:39:42 PDT
Ah crap. I overlooked the post review comments. I am happy with any naming. Waldo, guide me. What should I name how? I will do a little follow-up before I merge to m-c.
Comment 12 Chris Leary [:cdleary] (not checking bugmail) 2011-03-31 14:47:32 PDT
Comment 13 Chris Leary [:cdleary] (not checking bugmail) 2011-03-31 14:48:00 PDT
Whoops, sorry, this wasn't merged. Reopened.
Comment 14 :Ms2ger (⌚ UTC+1/+2) 2011-04-01 03:08:09 PDT
Yes it did?
Comment 15 Eric Shepherd [:sheppy] 2011-04-21 10:27:10 PDT

Also mentioned on Firefox 5 for developers.

Note You need to log in before you can comment on or make changes to this bug.