-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Agree on wt.datagrams.outgoingMaxAge vs wt.datagrams.writable.maxAge #305
Comments
@ricea I'd like to understand the argument against subclassing, since we have existing examples of "[subclassing] without a clear benefit": [Exposed=(Window,Worker), SecureContext]
interface SendStream : WritableStream /* of Uint8Array */ {
};
[Exposed=(Window,Worker), SecureContext]
interface ReceiveStream : ReadableStream /* of Uint8Array */ {
}; |
Yes, Subclassing creates implementation complexity and technical debt through excessive coupling. This leads to implementations being inflexible and fragile, which ultimately hurts users by leading to an unstable and unpredictable platform. There's also a real cost in terms of memory usage and startup time in adding more symbols to the global object. The cost for each individual symbol is small, but given the rate of evolution of the web platform the cumulative effect is large. |
Filed #306 for SendStream and ReceiveStream. |
Meeting
|
Closing for lack of interest. |
#267 (comment) got merged with unfinished discussion. This is fine in the interest of iteration, but I think we need WG consensus on API. Here's what got merged, along with
maxOutgoingSize
which is being proposed in #301:Here's what I propose(d) instead:
Organizing properties around natural objects we already expose seems cleaner and easier for web developers to understand, and seems better for encapsulation as well, versus relying on naming conventions to attempt to achieve the same correlation. In fact, having both seems discordant.
The argument that was raised against this was "avoid [subclassing] without a clear benefit". This seems like an implementation concern which would be lower on the priority of constituencies compared to web developer ergonomics.
The text was updated successfully, but these errors were encountered: