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

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Aug 29 15:12:40 PDT 2014


> one is a TypedArray instance and the other is an ordinary object.

let me try again ...

> Wouldn't that be inconsistent with `{}.toString.call(String.prototype)`
and all others ?

Isn't String.prototype an ordinary object ?




On Fri, Aug 29, 2014 at 4:32 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:

>
> 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 <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/5674246c/attachment.html>


More information about the es-discuss mailing list