Add more stuff about es6-shim HOT 22 CLOSED

Adding to this list: Array#keys, Array#values, Array#entries - they still need to decide if they accept a boolean param to request sparse iteration, but otherwise are in.

from es6-shim.

@ljharb Can you point us to documentation of Array#keys, Array#values, Array#entries , I could find the documentation of String#normalize in http://people.mozilla.org/~jorendorff/es6-draft.html but could not find the Array#keys

from es6-shim.

@dekajp http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.4.4.24 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.4.4.25 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.4.4.23

from es6-shim.

@ljharb @paulmillr I am trying to add String#raw , I am not confident if this is right. Can you please review ? i read here something about it - http://www.nczonline.net/blog/2012/08/01/a-critical-review-of-ecmascript-6-quasi-literals/

Here commit - 998fa49
Latest commit has better line spacing - adaa6be

from es6-shim.

@dekajp The spec for it is http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.5.3.4 - please feel free to make a pull request to add it, but please also include relevant tests for every condition specified in the spec. Thanks!

from es6-shim.

String.prototype.normalize ( form = "NFC" ) , http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.5.4.26

from es6-shim.

https://bugzilla.mozilla.org/show_bug.cgi?id=717379
Bug 717379 - Implement the new ES6 math functions
Status: RESOLVED FIXED

may be, es6-shim could use similar Math methods implementation to have same quality.

from es6-shim.

for example, current Math.hypot fails some tests:

 assertEq(Math.hypot(NaN, Infinity), Infinity)
 assertEq(Math.hypot(), NaN)
 assertEq(Math.hypot(1), NaN)
 assertNear(Math.hypot(1e300, 1e300), 1.4142135623730952e+300);

better version:

    Math.hypot = function (x, y, z) {
      x = Number(x);
      y = Number(y);
      z = z === undefined ? 0 : Number(z);
      x = Math.abs(x);
      y = Math.abs(y);
      z = Math.abs(z);
      if (x === Infinity || y === Infinity || z === Infinity) {
        return Infinity;
      }
      if (x !== x || y !== y || z !== z) {
        return NaN;
      }
      var t = Math.max(x, y, z);
      if (t === 0) {
        return 0;
      }
      x /= t;
      y /= t;
      z /= t;
      return t * Math.sqrt(z * z + y * y + x * x);
    };

Math.trunc is buggy for large integers
better version:

  Math.trunc = function(value) {
    value = Number(value);
    return value < 0 ? -Math.floor(-value) : Math.floor(value);
  };

from es6-shim.

@Yaffle According to the spec ( http://people.mozilla.org/~jorendorff/es6-draft.html ), none of your new tests apply - they're implementation-dependent, so we won't be changing Math.hypot's implementation or specs any time soon. However, I will fix the result of Math.hypot(NaN, Infinity) so it's correctly Infinity, thanks!

As for Math.trunc, that's also implementation-dependent, since the spec doesn't specify the behavior for large numbers. In addition, ~~n is equivalent to the ternary you specified, and also handles the Number coercion for you.

from es6-shim.

@ljharb,
very saddened

from es6-shim.

Bring your tears to TC39, not me :-)

from es6-shim.

@Yaffle According to the spec ( http://people.mozilla.org/~jorendorff/es6-draft.html ), none of your new tests apply - they're implementation-dependent, so we won't be changing Math.hypot's implementation or specs any time soon. However, I will fix the result of Math.hypot(NaN, Infinity) so it's correctly Infinity, thanks!

But according to spec all my tests are correct:
see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.8.2

the last test uses "assertNear" method, not "assertEq"
current implementation returns Infinity (because of overflow), so my implentation has a little better accuracy,
you can read more here - http://en.wikipedia.org/wiki/Hypot#Implementation - about over- or underflow in hypot impl.

As for Math.trunc, that's also implementation-dependent, since the spec doesn't specify the behavior for large numbers. In addition, ~~n is equivalent to the ternary you specified, and also handles the Number coercion for you.

the spec is very clear - http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.8.2.30

Returns the integral part of the number x, removing any fractional digits. If x is already an integer, the result is x.

so, it should work for any number

~~n is not equivalent because of convertion to int32, and the number coercion should be done before testing for Infinity and NaN according to spec

from es6-shim.

@Yaffle I'd be happy to take a look at a pull request. In the current implementation, NaN and Infinity checks are done before the ~~ Number conversion, so it's not an issue. In addition, numbers over Math.pow(2, 53) can't always be reliably represented, so behavior with numbers that large is often unspecified.

from es6-shim.

@ljharb,
Number.toInteger({valueOf: functon () {return "test me for NaN before convertion to Number, please!"; }};

from es6-shim.

@Yaffle your object there is not in fact the NaN literal, although it is "not a number". So, according to the spec, that should indeed be converted to a number.

from es6-shim.

@ljharb, you can run the code to see result:

var x = {valueOf: function () {return "test me for NaN before convertion to Number, please!"; }};
Object.is(x, NaN) === false;
Object.is(Number(x), NaN) === true;
so, spec-compatible Math.trunc should return NaN for it

convertion to number should be done only one time at the beginning of a method and i think, this is a good practise

from es6-shim.

@Yaffle interesting, that's a good point! i'll add a test with an object with a NaN-producing valueOf. if you want to refine it further, please submit a pull request - this issue is getting pretty crowded.

from es6-shim.

So will we never add Array#values because Sencha was stupid and used with?

from es6-shim.

I had not closed the PR yet. We will wait for conclusion from spec devs.

from es6-shim.

gotcha, thanks :-) the spec has been decided. there's a new (unshimmable) special symbol called "@@unscopeable" that's an array of properties that can't be overridden with "with".

Basically, we can't fix Sencha's issue with a shim, only with a fully compliant browser. That said, I still think we should shim it, since in a clean environment, it does what we expect.

from es6-shim.

link to the discussion please? we can merge then yeah

from es6-shim.

http://esdiscuss.org/notes/2013-07-23 has most of it

from es6-shim.