You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per our discussion in dfahlander/typeson-registry#2 (I'm planning to reply there shortly, btw), the idea of stream support was added and for the API, the methods are to be postfixed with *Stream".
I think consideration ought to be given for supporting the definition by the type of additional encapsulators/revivers . A type might need different implementations to return synchronously or as a stream (or promise), e.g., a file's contents.
In some cases, however, like converting a stream to a Promise, we might be able to do it for them. Thus
if a type defined a stream API, a user could nevertheless allow us to convert it to a Promise on their behalf when the stream finished.
Besides cases where multiple implementations might be necessary or desirable, offering alternative APIs might be desirable for polymorphism, e.g., if a stream is normally expected in one context but one particular type were only defined to simply return a string after revival, upon using the *Stream method, the synchronously obtained result could be turned into a stream by Typeson code on the user's behalf as could be done with Promises.
The text was updated successfully, but these errors were encountered:
Per our discussion in dfahlander/typeson-registry#2 (I'm planning to reply there shortly, btw), the idea of stream support was added and for the API, the methods are to be postfixed with *Stream".
I think consideration ought to be given for supporting the definition by the type of additional encapsulators/revivers . A type might need different implementations to return synchronously or as a stream (or promise), e.g., a file's contents.
In some cases, however, like converting a stream to a Promise, we might be able to do it for them. Thus
if a type defined a stream API, a user could nevertheless allow us to convert it to a Promise on their behalf when the stream finished.
Besides cases where multiple implementations might be necessary or desirable, offering alternative APIs might be desirable for polymorphism, e.g., if a stream is normally expected in one context but one particular type were only defined to simply return a string after revival, upon using the
*Stream
method, the synchronously obtained result could be turned into a stream by Typeson code on the user's behalf as could be done with Promises.The text was updated successfully, but these errors were encountered: