First crack at a Streams proposal
Tab Atkins Jr.
jackalmage at gmail.com
Sat Apr 20 17:10:19 PDT 2013
On Sat, Apr 20, 2013 at 4:13 PM, Sean Silva <silvas at purdue.edu> wrote:
> On Sat, Apr 20, 2013 at 3:47 PM, Tab Atkins Jr. <jackalmage at gmail.com>
>> On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter <i at izs.me> wrote:
>> > I'm not seeing what in this proposal can't be implemented in
>> > somewhere? Are there any programs that use these streams?
>> This is a fully-general counter-argument against literally everything
>> that doesn't require new primitives, and so is useless as an actual
>> argument. It would damn Promises/Futures, Sets, Maps, and a number of
>> other new things.
> I'm pretty sure there is no way to implement Maps with arbitrary keys in
> current JS.
It's possible, but lookup time is linear. You need some variety of
language support to get constant-time lookups.
> As for Promises/Futures, I think that the argument is equally forceful
> against them as it is to the proposals in this thread.
>> The valid version of this argument is about
>> *usefulness*, and there being unable to implement in current JS is a
>> supporting reason to add something, but not the only reason.
> My understanding from you wording is that you want this to be standardized
> into ECMAScript. That means that this change would be shipped in billions of
> devices and require implementation and testing effort across the globe and
> across every vendor. Are you sure it's utility would not be diminished if
> you just put a nice working implementation on github and register it with
> the various package managers that make installing and using such code dead
> simple? That would be a huge win since people would be able to start using
> it immediately.
> Concretely, compared to putting it on github and registering with package
> managers, what percentage usefulness increase do you expect to see by having
> this standardized?
> I think you're completely right, "The valid version of this argument is
> about *usefulness*", except it's about usefulness of standardizing it
> compared to other ways of making the code available, and not about the
> intrinsic usefulness of the API (which, I'll point out, does not appear to
> be convincingly established).
Whether TC39 ends up taking over standardization of promises/futures
or not, they're in the DOM and will be used by new standards.
I write standards for a living, so I'm well aware of the cost of
adding features. I believe that addressing the use-cases of
functional reactive programming *is* important enough to justify
adding some new concepts to help them out, because it's an
intrinsically useful and high-value abstraction for a lot of
interactions with the DOM and with the user. Event streams are an
early attempt by me to put something together for this, and I was
using es-discuss as a sounding board and design help for it.
Now that I've got a handle on what I think a good design is, my plan
is to retreat and spend some time studying and documenting existing
stream patterns in libraries, to try and discover what I might be
missing, or what areas I'm over/under-addressing. When I'm done, I'll
report back with my findings.
More information about the es-discuss