Accept ArrayBuffer (and typed array/data view?) anywhere Buffer is allowed in the API

[domenic]

That is, update fs, http, streams, etc.

This is a proposal, but I would think with @trevnorris's work on making Buffer a subclass of Uint8Array, it seems likely to be not too hard...

On the web the best practice has emerged that when accepting arguments, allow any of ArrayBuffer or typed array or DataView, which is why I think more than just Buffer | ArrayBuffer would make sense.

What do people think? @trevnorris, am I understanding correctly that after your work lands this would not be very hard?

[mscdex]

I'm guessing that this would be within the confines of core and not 3rd party addons (at least such addons would need to explicitly support ArrayBuffers also)?

[domenic]

@mscdex good question. I am not sure how third-party addons get access to the underlying void*. If they all go through a function, we should be able to modify that function to accept any of these...

[trevnorris]

@domenic if you pass new Buffer(new ArrayBuffer(5)) would you expect the data to be copied or pointed to by the new buffer instance?

Either way it can be done. This was actually on my list of things to implement, but I wanted to keep the initial PR small.

TBH it wouldn't be hard to support ArrayBuffer in most of the API. e.g.

var buf = new Buffer(16);
var ab = new ArrayBuffer(16);
buf.copy(ab);

[trevnorris]

Third party support shouldn't be a problem. The native Buffer API still hands back the void* that the ArrayBuffer points to. So anyone can operate on it as they usually have.

[domenic]

@trevnorris to clarify I wasn't just talking about the buffer API; I was talking about the whole io.js API surface area. FS, streams, etc. Not sure if that came across in the OP... editing now.

if you pass new Buffer(new ArrayBuffer(5)) would you expect the data to be copied or pointed to by the new buffer instance?

Given how new Uint8Array(new ArrayBuffer(5)) behaves I'd expected pointed to, but I am more used to typed arrays than I am to buffers to be honest...

[domenic]

This was actually on my list of things to implement, but I wanted to keep the initial PR small.

Yeah definitely, can leave this for a minor version probably.

[trevnorris]

A pointer is fine with me.

If we say that an ArrayBuffer is treated as binary data then this is feasible. Typed Arrays can be a little tricky because of user's expectations (e.g. is the "length" to be written the byte length or the index length). But it can definitely be investigated.

[obastemur]

+1 for even talking ArrayBuffer / node.JS Buffer..

The native Buffer API still hands back the void* that the ArrayBuffer points to.
A pointer is fine with me.

Let's say variable X = ArrayBuffer while the Y = Buffer (points to X's memory). As long as Y is alive, there is a need to keep X from GC.

A naive hope / question / discussion, (although it's a clear break in the API) why not just use ArrayBuffer and node.JS buffer as it's view (optional) ?

[feross]

if you pass new Buffer(new ArrayBuffer(5)) would you expect the data to be copied or pointed to by the new buffer instance?

I would expect pointed to. All other argument types to the Buffer constructor get copied, but they're all array-like (have length property and are indexable). ArrayBuffer is not array-like, so it's not a huge deal if we add a special case here. It's more useful to have it share memory, I think.

[Trott]

This has been inactive for a while. I'm going to throw a help wanted label on it, but feel free to remove it if, you know, help isn't actually wanted. (Why do I type these things?)

[trevnorris]

This would be more easily done now that Buffer is a Uint8Array. In fact the native Buffer::HasInstance() only checks if the object is a Uint8Array instance. Change would be tedious and require a lot of documentation updates. Especially since it may be confusing out of context reading an API takes a Uint8Array, which Buffer is, but not know that you can actually pass a Buffer.

ArrayBuffer would require a bit more work, but also doable now.