On Sat Jan 03 2015 at 3:56:38 PM Brendan Eich <brendan at mozilla.org> wrote:

> Axel Rauschmayer wrote:
> >> On 03 Jan 2015, at 19:52, Brendan Eich <brendan at mozilla.org
> >> <mailto:brendan at mozilla.org>> wrote:
> >>
> >> None of the objects in the examples bz cited are Arrays -- what did
> >> you mean?
> >
> > When I though of `+` being used inside square brackets, I only thought
> > of strings, not of numbers (first example).
> >
> > In the first example, `this` is at least array-like. Otherwise,
> > `slice` wouldn’t work.
>
> Sure, but you wrote "Arrays", not array-likes. Also bracketing for
> computed property access works with any object, not just array-likes.
>
> Sorry to be nit-picky but precision required here ;-).
>
>
Right, but regardless of how the potential footgun is loaded, the exception
is the divergence. That specifically is what I want us to look at—is this
the right thing to do here? Currently, user code can do things like this:

  var a = {};
  //... sometime later...
  a[o + "_idfoobarwhatever"] = "my important stuff";

And even if `o` isn't a what the author expected, execution proceeds. I
still think that the exception is a good path forward, but I may not be
right about that.

The exception...

A. Requires user code to be more thoroughly tested—which is a good thing,
but inexperienced programmers won't think so.
B. Diverges from the well known implicit coercion behaviors that the
language has had for 20 years (@Brendan: sorry for the reminder ;). This is
arguably both a good thing and a bad thing (C, D, E, F)
C. Prevents user code from doing the wrong thing (assuming that A is
adhered to).
D. Produces a surprising behavior (in comparison to all other implicit
coercion operations)
E. W/r to A and C, most code will need some kind of guard, just to avoid
the exception, ie. either try/catch or `if (typeof s !== "symbol") ...`
F. Not directly related, but querySelectorAll(...) throws if the selector
is invalid, which is widely considered a poor design choice for that API.
This is something that _all_ DOM-centric libraries paper over, because
authors would prefer that an invalid selector simply produce the equivalent
of "no found elements", than throwing an exception.

Subjectively: I think it's nice in theory, but bad in practice.

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

Right, but regardless of how the potential footgun is loaded, the exception
is the divergence. That specifically is what I want us to look at—is this
the right thing to do here? Currently, user code can do things like this:

```js
  var a = {};
  //... sometime later...
  a[o + "_idfoobarwhatever"] = "my important stuff";
```

And even if `o` isn't a what the author expected, execution proceeds. I
still think that the exception is a good path forward, but I may not be
right about that.

The exception...

A. Requires user code to be more thoroughly tested—which is a good thing,
but inexperienced programmers won't think so.
B. Diverges from the well known implicit coercion behaviors that the
language has had for 20 years (@Brendan: sorry for the reminder ;). This is
arguably both a good thing and a bad thing (C, D, E, F)
C. Prevents user code from doing the wrong thing (assuming that A is
adhered to).
D. Produces a surprising behavior (in comparison to all other implicit
coercion operations)
E. W/r to A and C, most code will need some kind of guard, just to avoid
the exception, ie. either try/catch or `if (typeof s !== "symbol") ...`
F. Not directly related, but querySelectorAll(...) throws if the selector
is invalid, which is widely considered a poor design choice for that API.
This is something that _all_ DOM-centric libraries paper over, because
authors would prefer that an invalid selector simply produce the equivalent
of "no found elements", than throwing an exception.

Subjectively: I think it's nice in theory, but bad in practice.