On Mon, Apr 15, 2013 at 1:51 PM, Andrea Giammarchi
<andrea.giammarchi at gmail.com> wrote:
> It's a nice effort but I agree with Nuno that fragmentation even on these
> things already in production (despite the versioning) out there and already
> working practically for the real-world isn't any good for the next future of
> the JS community.

Fragmentation of concept is exactly what standardization helps to
solve - the role of standards is to, well, standardize, especially
after the market has explored the problem space already.  Futures were
long-overdue when Anne finally specced them, having been around in
lots of languages including JS in many forms, and I think Streams are
in a similar boat.

> Also, JS has been kept general purpose enough, I would not try to influence
> the language too much after DOM and W3C APIs and I thought this was also
> same idea of TC39.

I don't understand this sentence.  It *sounds* like you're trying to
say that Streams aren't general-purpose enough for JS to standardize,
and should be left to DOM/W3C to do.  Is this correct?

If so, I disagree, and think that several other people on es-discuss
do as well.  (For example, Alex, Yedua, and Dave have been responding
to me about this proposal in Twitter.)  In general, a Stream is just
another container type, and is as general as an Array or Set.  Plenty
of *specific* instances or subclasses of Streams are appropriate for
individual DOM/etc specs to define, but we need to agree on the
general concept first, and es-discuss folks seem well-suited to help
develop this.

~TJ

On Mon, Apr 15, 2013 at 1:51 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> It's a nice effort but I agree with Nuno that fragmentation even on these
> things already in production (despite the versioning) out there and already
> working practically for the real-world isn't any good for the next future of
> the JS community.

Fragmentation of concept is exactly what standardization helps to
solve - the role of standards is to, well, standardize, especially
after the market has explored the problem space already.  Futures were
long-overdue when Anne finally specced them, having been around in
lots of languages including JS in many forms, and I think Streams are
in a similar boat.

> Also, JS has been kept general purpose enough, I would not try to influence
> the language too much after DOM and W3C APIs and I thought this was also
> same idea of TC39.

I don't understand this sentence.  It *sounds* like you're trying to
say that Streams aren't general-purpose enough for JS to standardize,
and should be left to DOM/W3C to do.  Is this correct?

If so, I disagree, and think that several other people on es-discuss
do as well.  (For example, Alex, Yedua, and Dave have been responding
to me about this proposal in Twitter.)  In general, a Stream is just
another container type, and is as general as an Array or Set.  Plenty
of *specific* instances or subclasses of Streams are appropriate for
individual DOM/etc specs to define, but we need to agree on the
general concept first, and es-discuss folks seem well-suited to help
develop this.

~TJ