well, if the purpose is different and you need to describe streams as "observables" or "signals" then I would suggest to change naming convention so nobody will ever be confused again.
On Mon, Apr 15, 2013 at 2:36 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I think a large part of the confusion here is that when Tab says > "streams" he really means "observables" or "signals." As you point out, > this would be completely inappropriate as a stream API, as it does indeed > ignore many of the lessons Node learned. Surprisingly, it doesn't seem to > draw on any of the existing observable or signal APIs that I've seen > either, instead being some entirely new hybrid of promises and the nascent > monads-in-JS movement. > ------------------------------ > From: Nuno Job <nunojobpi...@gmail.com> > Sent: 4/15/2013 15:43 > To: Tab Atkins Jr. <jackalm...@gmail.com> > Cc: es-discuss <es-discuss@mozilla.org> > Subject: Re: First crack at a Streams proposal > > Node.js has multiple iterations on Streams, and those were made in the > hope to make them better. It's hard and has been an ongoing effort to make > it perfect. > > That said it's quite surprising to see smart folks come to such > different conclusions. Perhaps it's the lack of real life implementations > and how these things affect real life programs and companies that use > javascript. Almost all these concepts would have no chance to make it to > node core. And some of these concepts are fairly advanced, when in node it > took years to get get the basics right (the rest was left to npm and > developers) > > Nuno > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
