in case my question wasn't clear ...
`String.prototype instanceof String` is `false` and `typeof
String.prototype` is `object`
So, my concern, and the least surprise I was talking about, are still
there. Feel free to ignore though
Regards
On Fri, Aug 29, 2014 at 11:12 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> > 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 <al...@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 <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
