Simpler stream construction

[sonewman]

This is a PR to support suggested functionality discussed in issue #102 to be discussed at WG Meeting: #106

• Create prototype with ability to set required methods through stream construction
• Discuss / review implementation with WG (@iojs/streams) members.
• Finalise on best implementation
• Add necessary unit tests to prove functionality

(Subsequent changes will likely be rebased into one commit)

Please review - Do Not Merge

[chrisdickinson]

One thing that will be a prerequisite before this gets merged is to put in the work to reverse the flow of readable-stream into io.js.

[chrisdickinson]

Hm, I'm -0 on adding this if it's a shorthand for _read = fn – accepting functions into the constructor is a natural jumping off point for the other changes we'd like to see with streams, and if we don't take that opportunity when we add this functionality we'll have lost the chance to do so in the future (this roughly echoes my position from the other issue.)

[sonewman]

Ahh so you were suggest jump straight to 'start' & 'pull'?

[sonewman]

That's fine, it was more like a rough here's what I was suggesting, let's discuss. I don't think it is necessarily the final solution.

[sonewman]

It's definitely best if we do this properly so we are all in agreement, I am just keen to prompt discussion.

[chrisdickinson]

Per the WG meeting: everyone was pretty much +1 on this going in if the keys for _transform and _write don't conflict with WHATWG-style keys.

[sonewman]

@chrisdickinson cool, well I'll wait for @domenic to come back with some feedback before writing some simple tests.

As you know I have raised some questions in (#102) maybe they were your initial concerns before?

[domenic]

OK, so basically the semantics are compatible in all cases. (Except readable streams, but we dodge that by using read here which doesn't conflict with WHATWG streams start and pull.) This harmoniousness includes writev and transform/flush, which aren't finalized for WHATWG streams yet but I am pretty sure what they'll look like. All the important things are there: the same hooks are async in the same way, and roughly the same data is passed in.

In general the parameters don't match up, even ignoring the promise/callback issues. So people won't be able to transparently swap out new stream.Readable({...}) with new ReadableStream({ ... }). But we knew that would happen.

So, +1 to proceed.

[chrisdickinson]

@domenic Awesome, thanks for looking into this.

@sonewman So, in the interest of expedience, you might re-open this PR over on iojs/io.js, and cc me there. We can merge it in there, then use the existing slurping tools to bring it into this repo. Great work!

[sonewman]

@domenic @chrisdickinson awesome things for the update, I will knock up some tests and raised as a PR in iojs/io.js also.

[sonewman]

This is in core, so I am going to close