You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I have an object with a buffer attached and I need to be able to pass around that Buffer but ensure that it won’t mutate.
Describe the solution you'd like
A method on Buffer instances to put it into a “read only mode” would be ideal. I’d prefer it not be in the constructor so that I don’t have to perform a memcopy in order to get it.
Describe alternatives you've considered
There isn’t much you can do except force a full copy every time you pass it around, which is pretty bad. Object.freeze() won’t work because all the mutations happen through methods that are effectively invisible to Object.freeze().
However, Object.freeze() has some negative performance implications while implementing this in the Buffer object itself would not have the same problems. This would be a nice features of Node.js Core.
I think this would have to be a language feature, because the only difference between Buffer and Uint8Array is that the former has a few more prototype methods.
You can also define a proxy over the buffer though that would probably be expensive since it'd be hit on every access. I wonder if a proxy with only a set trap (and not a get trap) would be slow or not.
I think read-only ArrayBuffers would be a useful feature to represent memory that should not or cannot be written to. However, if we still need to write to the memory through a different object, we might need two ArrayBuffers, which would technically act like a View I guess?
This is an interesting problem, and I agree that it would probably be best solved at the engine level and across Javascript as a whole.
Is the idea for the API that you would start with a mutable buffer and at some point freeze it?
Do you want a read-only view on something which may still change out from under you? If so, a Proxy-based solution may work, if the performance can be good enough. Otherwise, we need to freeze the underlying ArrayBuffer somehow.
For context, would it be reasonable to copy the Buffer into an immutable structure, or would that be too slow for your needs?
Reacted by Nikita Skovoroda, Peter Hoddie and Sandeep Singh
Copying would certainly be too slow, at least for the cases where I think this would be useful. A read only view on an otherwise mutable structure would work for most cases I could imagine but @mikeal may have other requirements. The most common case I would imagine for this is some bit of code that creates/mutates the buffer then passes it off to some other context, after which it would no longer be modified.
On Sat, Apr 6, 2019, 3:13 PM Tobias Nießen ***@***.***> wrote:
I agree with @jasnell <https://github.com/jasnell>. Would it be possible
to allow freezing both buffers and views? For example,
- ArrayBufferView.freeze() marks the view as "frozen", preventing all
future write accesses through the view.
- ArrayBuffer.freeze() marks the buffer as "frozen", preventing all
future write accesses to the buffer, including write accesses through views.
Would this work and cover all use cases? It would certainly cause some
overhead, but still much less than copying the data into a new buffer.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27080 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAACQ_-dPvJR3z1Ke1yys7ZlZn2s8tFLks5veRwagaJpZM4cbpZV>
.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
I certainly will use this feature a lot, when reading from cached buffers, I likely use subarray for getting an view and will be very useful if this subarray are only read only to not modify the cached buffer
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
Just FYI – there is a proposal at TC39 for read-only collections which provides for immutable ArrayBuffers. The champions are @erights and me. It hasn't been very active, so it may still be appropriate to close this here.
Reacted by Ciro Spaciari, Tierney Cyren, Jordan Harband and Raphaël Thériault
Activity
[-]Immutable Buffer `buffer.readonly()`[/-][+]Feature: Immutable Buffer `buffer.readonly()`[/+]addaleax commentedon Apr 3, 2019
I think this would have to be a language feature, because the only difference between
BufferandUint8Arrayis that the former has a few more prototype methods.addaleax commentedon Apr 3, 2019
/cc @nodejs/open-standards (I guess?)
jasnell commentedon Apr 4, 2019
This would definitely be interesting but I agree we might want to push to tc39 first
benjamingr commentedon Apr 4, 2019
You can also define a proxy over the buffer though that would probably be expensive since it'd be hit on every access. I wonder if a proxy with only a set trap (and not a get trap) would be slow or not.
devsnek commentedon Apr 4, 2019
you'd also want to intercept
.bufferI assumeaddaleax commentedon Apr 4, 2019
Yeah, that’s a good point to figure out when bringing this to TC39 – would we want read-only ArrayBufferViews, or read-only ArrayBuffers, or both?
tniessen commentedon Apr 4, 2019
I think read-only
ArrayBuffers would be a useful feature to represent memory that should not or cannot be written to. However, if we still need to write to the memory through a different object, we might need twoArrayBuffers, which would technically act like aViewI guess?ljharb commentedon Apr 4, 2019
Borrowing ArrayBuffer.prototype methods and .calling them on a Proxy would throw, though, wouldn’t it? (since internal slots don’t tunnel)
littledan commentedon Apr 6, 2019
This is an interesting problem, and I agree that it would probably be best solved at the engine level and across Javascript as a whole.
Is the idea for the API that you would start with a mutable buffer and at some point freeze it?
Do you want a read-only view on something which may still change out from under you? If so, a Proxy-based solution may work, if the performance can be good enough. Otherwise, we need to freeze the underlying ArrayBuffer somehow.
For context, would it be reasonable to copy the Buffer into an immutable structure, or would that be too slow for your needs?
jasnell commentedon Apr 6, 2019
Copying would certainly be too slow, at least for the cases where I think this would be useful. A read only view on an otherwise mutable structure would work for most cases I could imagine but @mikeal may have other requirements. The most common case I would imagine for this is some bit of code that creates/mutates the buffer then passes it off to some other context, after which it would no longer be modified.
tniessen commentedon Apr 6, 2019
I agree with @jasnell. Would it be possible to allow freezing both buffers and views? For example,
ArrayBufferView.freeze()marks the view as "frozen", preventing all future write accesses through the view.ArrayBuffer.freeze()marks the buffer as "frozen", preventing all future write accesses to the buffer, including write accesses through views.Would this work and cover all use cases? It would certainly cause some overhead, but still much less than copying the data into a new buffer.
mikeal commentedon Apr 6, 2019
30 remaining items
github-actions commentedon Sep 19, 2022
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
cirospaciari commentedon Oct 6, 2022
I certainly will use this feature a lot, when reading from cached buffers, I likely use subarray for getting an view and will be very useful if this subarray are only read only to not modify the cached buffer
github-actions commentedon Apr 5, 2023
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
bnoordhuis commentedon Apr 5, 2023
To recap: this needs someone to champion a proposal at TC39.
I'm going to close the issue because, while the discussion is interesting, it's inactionable for Node.js.
phoddie commentedon Apr 5, 2023
Just FYI – there is a proposal at TC39 for read-only collections which provides for immutable ArrayBuffers. The champions are @erights and me. It hasn't been very active, so it may still be appropriate to close this here.