Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Aug 29 08:32:07 PDT 2014

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.

another way to approach this issue would be to include the equivalent of:
   if (this.constructor.prototype === this) return "Object"
in the @@toStringTag getter for such classes.


> Regards
> On Fri, Aug 29, 2014 at 1:44 AM, Allen Wirfs-Brock <allen at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140829/85f9f455/attachment.html>

More information about the es-discuss mailing list