Sparse/dense property storage will want this API split to make indexed accesses more efficient.
I queried the newsgroup about making the change (versus adding yet another kind of property-access API), and no one expressed concern. It's also worth noting that every use of these methods that I found in mozilla-central was using only the non-negative half of the index space. I expect this is the common case. I wonder, even, how much anyone ever used negative elements -- I'd guess element stuff is mostly used for arrays and arraylike things, and you're not going to hit negative elements there.
(I did end up changing some Mozilla callers to avoid possible compiler warnings. Technically I probably could have gotten away without doing this, but it seemed a good time to clean up signage usage in that code when I already had to audit them to make sure none depended on being able to pass negative indexes.)
Created attachment 550917 [details] [diff] [review]
Change JS_DefineElement and adjust users
I'm doing one patch per method changed, to keep things bite-sized. There's no particular reason it couldn't all be concatenated together into one patch, it just might get (a little bit) big.
Created attachment 550919 [details] [diff] [review]
Created attachment 550920 [details] [diff] [review]
Created attachment 550921 [details] [diff] [review]
Created attachment 550922 [details] [diff] [review]
Created attachment 550923 [details] [diff] [review]
Created attachment 550924 [details] [diff] [review]
http://hg.mozilla.org/integration/mozilla-inbound/rev/30dd110a4ed6 (not part of this bug, but required for the last two patches to be definitely comprehensive)