On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:

> It's also deceptive: it makes you think `Array.of` and `Array.from` are
> functions, when in reality they are definitely methods.
>

Yes, you're right.


What about Array subclasses? `from` and `of` are "inherited" when Array is
subclassed, so these:

22.1.2.3 4 & 5 (
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of)
22.1.2.1 8.a & 8.b (
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.from)
22.1.2.1 13 & 14

Which are are how `from` and `of` determine what to construct, will be
replaced with a single step, being one of:

Let A be the result of calling the [[Construct]] internal method of C with
an empty argument list.
Let A be the result of calling the [[Construct]] internal method of C with
an argument list containing the single item len.

But surely this step will also have to be guarded by IsCallable(this),
which that means this:

If IsConstructor(C) is true, then
  Let A be the result of calling the [[Construct]] internal method of C
with an empty argument list.
Else,
  Let A be ArrayCreate(0).

Becomes:

If IsCallable(C) is true, then
  Let A be the result of calling the [[Construct]] internal method of C
with an empty argument list.
Else,
  Let A be ArrayCreate(0).


Or maybe that's not necessary? Is it preferable to just throw when someone
writes any of these:

let of = Array.of;
of(1,2,3,4);

let from = Array.from;
from(arrayLikeOrIterable);

let List = {
  of: Array.of
};

List.of(1, 2, 3, 4);

(Note that `Array.isArray` doesn't cease to work correctly when aliased)

With the IsConstructor or IsCallable guard, these "just work"; without any
guard, they'll throw TypeError exceptions: "object is not a function" or
"undefined is not a function" (in strict mode). Neither of these errors are
very obvious. Of course this can all be fixed with .bind() or a "bind"
operator, but it just seems unfortunate to throw out something that's not
harming the spec in favor something that might be problematic in end user
code.


Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140611/4b9d84b5/attachment.html>

On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:

> It's also deceptive: it makes you think `Array.of` and `Array.from` are
> functions, when in reality they are definitely methods.

Yes, you're right.


What about Array subclasses? `from` and `of` are "inherited" when Array is
subclassed, so these:

- 22.1.2.3 4 & 5 (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of)
- 22.1.2.1 8.a & 8.b (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.from)
- 22.1.2.1 13 & 14

Which are are how `from` and `of` determine what to construct, will be
replaced with a single step, being one of:

- Let A be the result of calling the [[Construct]] internal method of C with an empty argument list.
- Let A be the result of calling the [[Construct]] internal method of C with an argument list containing the single item len.

But surely this step will also have to be guarded by IsCallable(this),
which that means this:

- If IsConstructor(C) is true, then
  - Let A be the result of calling the [[Construct]] internal method of C with an empty argument list.
- Else,
  - Let A be ArrayCreate(0).

Becomes:

- If IsCallable(C) is true, then
  - Let A be the result of calling the [[Construct]] internal method of C with an empty argument list.
- Else,
  - Let A be ArrayCreate(0).


Or maybe that's not necessary? Is it preferable to just throw when someone
writes any of these:

```js
let of = Array.of;
of(1,2,3,4);

let from = Array.from;
from(arrayLikeOrIterable);

let List = {
  of: Array.of
};

List.of(1, 2, 3, 4);
```

(Note that `Array.isArray` doesn't cease to work correctly when aliased)

With the IsConstructor or IsCallable guard, these "just work"; without any
guard, they'll throw TypeError exceptions: "object is not a function" or
"undefined is not a function" (in strict mode). Neither of these errors are
very obvious. Of course this can all be fixed with .bind() or a "bind"
operator, but it just seems unfortunate to throw out something that's not
harming the spec in favor something that might be problematic in end user
code.