On Aug 29, 2014, at 3:09 AM, Andrea Giammarchi wrote:
> Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and
> all others ?
>
> I'd personally expect `{}.toString.call(new Float32Array([1,2,3]))` to
> produce same result of `{}.toString.call(Float32Array.prototype)`, seems like
> the "least surprise"
Why one is a TypedArray instance and the other is an ordinary object.
BTW,
another way to approach this issue would be to include the equivalent of:
```js
if (this.constructor.prototype === this) return "Object"
```
in the @@toStringTag getter for such classes.
Allen
>
> Regards
>
>
> On Fri, Aug 29, 2014 at 1:44 AM, Allen Wirfs-Brock <al...@wirfs-brock.com>
> wrote:
>
> On Aug 28, 2014, at 2:56 PM, Jeff Walden wrote:
>
> > Per latest draft, %TypedArray%.prototype[@@toStringTag] is a getter that
> > throws a TypeError if |this| doesn't have the internal slots of a typed
> > array. Neither %TypedArray%.prototype nor
> > {{Ui,I}nt{8,16,32},Float{32,64}}.prototype have these internal slots. So
> > the builtin Object toString method, called on any of these objects, will
> > throw a TypeError. Is this wise? I suspect there's debugging code out
> > there that expects that toString doesn't throw on at least the typed array
> > prototypes (seeing as it doesn't throw in any engine I'm aware of right
> > now, tho the returned string is inconsistent).
>
> This seems like a special case of the general problem that methods, defined
> on prototype objects, that have dependencies upon instance state such as
> internal slots or exotic internal methods won't work if applied to their
> containing prototypes when those prototypes do not provide the expected
> instance state or behavior.
>
> I don't think there is a general solution to this problem. It's a place
> where the ESs "class model" is a leaky abstraction.
>
> As a special case solution (in support of universal toString support) we
> could make all such @@toStringTag getters all back to returning "Object" if
> the instance requirements they check for are not met.
>
> I'd happily accept a bug on that.
>
> In an earlier iteration of O.p.toString I was eating exceptions thrown when
> getting the @@toStringTag value. But that sort of exception suppression
> wasn't very well received.
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
