Skip to content

GenericTransformStream mixin vs. subclassing #1074

Open
@domenic

Description

@domenic

#1073 works to formalize and formally recommend the pattern used by https://encoding.spec.whatwg.org/ and https://wicg.github.io/compression/, of wrapping up an internal TransformStream and re-exposing it through readable and writable properties.

However, I've lost track of why we do this, instead of subclassing TransformStream.

NativeFS shows how to subclass WritableStream, and #1073 makes it much easier by allowing you to reduce much of the boilerplate there to [=WritableStream/Set up=] [=this=] with |writeAlgorithm| and |closeAlgorithm|. It seems we could similarly make subclassing TransformStream easy.

This isn't very consequential. In general I expect the most noticable effect to be on instanceof. I don't expect us to add any significant public APIs to TransformStream that we'd want subclasses to inherit.

However, I am a bit concerned about recommending a totally different pattern for TransformStream than we do for WritableStream and ReadableStream. So I thought it'd be worth raising, and seeing if perhaps we want to change course.

Metadata

Metadata

Assignees

No one assigned

    Labels

    other spec interfaceHow the Streams spec interfaces with other specifications

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions