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

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Aug 29 03:09:13 PDT 2014

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"


On Fri, Aug 29, 2014 at 1:44 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>

> 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/9521720b/attachment-0001.html>

More information about the es-discuss mailing list