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
