Expose public APIs for converting doubles to signed/unsigned int per ECMA spec

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: bz, Assigned: gal)

Tracking

({dev-doc-complete})

Trunk
x86
Mac OS X
dev-doc-complete
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

Could be useful in places where we have to write bindings.
(Assignee)

Comment 1

7 years ago
Created attachment 509339 [details] [diff] [review]
patch
(Assignee)

Updated

7 years ago
Attachment #509339 - Flags: review?(bzbarsky)
(Assignee)

Updated

7 years ago
Attachment #509339 - Flags: approval2.0?
(Assignee)

Comment 2

7 years ago
NPOTB, not currently in use.
Comment on attachment 509339 [details] [diff] [review]
patch

Land it.
Attachment #509339 - Flags: review?(bzbarsky)
Attachment #509339 - Flags: review+
Attachment #509339 - Flags: approval2.0?
Attachment #509339 - Flags: approval2.0+
Comment on attachment 509339 [details] [diff] [review]
patch

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?

/be
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.
Agree with comment 5, which leaves adding "ECMA" to the parallel DoubleTo names. Agreed?

/be

Updated

7 years ago
Blocks: 630052
(Assignee)

Updated

6 years ago
Attachment #509339 - Flags: approval2.0+
This is blocking some of my work. Any chance this could be landed soonish?
(Assignee)

Comment 8

6 years ago
http://hg.mozilla.org/tracemonkey/rev/8359361f8a7b
Whiteboard: fixed-in-tracemonkey
What about comment 4 through comment 6?
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.
(Assignee)

Comment 11

6 years ago
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.
http://hg.mozilla.org/mozilla-central/rev/8359361f8a7b
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whoops, sorry, this wasn't merged. Reopened.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

6 years ago
Keywords: dev-doc-needed
Yes it did?

http://hg.mozilla.org/mozilla-central/file/1a89509e25e4/js/src/jsapi.cpp#l523
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Documented:

https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_DoubleToInt32

Also mentioned on Firefox 5 for developers.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.