Skip to content

Question: Should Streams have the prototype for Symbol.toStringTag and toString declared?Β #952

Closed

Description

@ThisIsMissEm

In certain implementations of whatwg streams, I've come across them not implementing toString or Symbol.toStringTag on the prototype meaning that if you're trying to find out if you've been given a stream (or another data type) then you have to rely on duck typing.

In the following, I'd expect to see "[object ReadableStream]" returned:

let r = new ReadableStream()
// ReadableStreamΒ {}
r.toString()
// "[object Object]"
> Object.prototype.toString.call(r)
// "[object Object]"

In Safari these all return as I'd expect, in Chrome and Firefox they return "[object Object]". The spec doesn't actually specify the toString behavior.

Activity

  1. ThisIsMissEm commented on Aug 31, 2018

    @ThisIsMissEm
    Author

    (Relatedly I've opened an issue on the node.js FormData module for the same issue: form-data/form-data#396 )

  2. ricea commented on Aug 31, 2018

    @ricea
    Collaborator

    Interesting point. It looks like "[object ReadableStream]" would be correct. I don't think it would hurt to be explicit about this in the standard. I'm not sure of the best way to do it. Perhaps specifying the value of ReadableStream.prototype[Symbol.toStringTag] is sufficient?

    @domenic Can you suggest the correct way to specify this, off the top of your head?

  3. domenic commented on Aug 31, 2018

    @domenic
    Member

    Currently the spec required [object Object]. We could change this if we wanted, but I'm not sure what the benefits would be. People can just use x.constructor.name for the same effect.

  4. ricea commented on Aug 31, 2018

    @ricea
    Collaborator

    I think the benefit is consistency. Language objects Promise, Map, WeakMap, and WeakSet all return
    "[object Foo]", and AFAIK all IDL types that don't specifically override it also return "[object Foo]". Which leaves streams as a weird odd-one-out.

  5. added 3 commits that reference this issue on Apr 13, 2020
    0674415
    c5b5e05
    ca89482
  6. added a commit that references this issue on Jun 11, 2020
    caf3cea
  7. added a commit that references this issue on Jun 3, 2021
    7dbcfed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions