First crack at a Streams proposal

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Apr 15 14:12:50 PDT 2013


I've implemented Alex Future proposal in JS before he did as prototype and
for tests.

However, Futures aren't used that much in node.js and spec'd like that are
nice.

However, I would not compare those two things.

If you propose Streams after Futures where Futures are less common in node
but Streams are one of the major things I think you should consider more
the current used node approach.

I don't see Future and Stream as different containers of the same thing
with identical functionality, sorry.

This is all I am saying.

Regards


On Mon, Apr 15, 2013 at 2:04 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130415/63ece47f/attachment-0001.html>


More information about the es-discuss mailing list