Skip to content

Disallow mutating state of Blob/File objects #75

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
annevk opened this issue Mar 22, 2017 · 6 comments · May be fixed by #154
Open

Disallow mutating state of Blob/File objects #75

annevk opened this issue Mar 22, 2017 · 6 comments · May be fixed by #154

Comments

@annevk
Copy link
Member

annevk commented Mar 22, 2017

In particular, I think we should no longer add something like close() and make that an invariant of these objects.

That way there's no longer a need for defensive cloning (through serializing/deserializing) of these objects, which helps with whatwg/url#277.

Making a note of this somewhere in the document seems sufficient.

@mkruisselbrink
Copy link
Collaborator

I agree that defining Blob/File as fully immutable (which they more or less already are currently) would definitely be a nice thing. I'm not sure if we can really get rid of defensive cloning though. For example reading a File can always cause a NotReadableError if the snapshot state of the File no longer matches the state of the underlying storage (although the whole concept of this snapshot state isn't defined very well. I don't think we want to start requiring user agents to actually do defensive cloning themselves every time they create a File).

@annevk
Copy link
Member Author

annevk commented Apr 2, 2017

Defensive cloning doesn't help with snapshot state I think, since we wouldn't want to require cloning to copy the bytes, cloning should just copy a pointer.

@mkruisselbrink
Copy link
Collaborator

Ah yes, good point. So yeah, I should definitely add a note somewhere to make it explicit that blob's are immutable, noting that the snapshot state might still cause the same operation on the same blob to behave differently at different times.

@andrew-aladev
Copy link

I agree that defining Blob/File as fully immutable (which they more or less already are currently) would definitely be a nice thing.

I don't think so. You like functional programming. You just forgot that you are making API for whole Earth. Some people don't like it. Why do you think that you can force your programming style?

@andrew-aladev
Copy link

In particular, I think we should no longer add something like close() and make that an invariant of these objects.

If you don't want to maintain blob/file state inside - people will have to invent their own bicycle wrapper that does this (with some method like toNative()). If you are going to make user applications more error prone - you are doing fine job.

@guest271314
Copy link

guest271314 commented Apr 8, 2019

@andrew-aladev If toNative() only sets the name property of the File object FormData set() method can be utilized #126 (comment)

mkruisselbrink added a commit that referenced this issue May 21, 2020
This redefines how blobs work by adding internal slots and hooks to
support Blob objects backed by various sources of data. By doing so this
tries to make more explicit how various edge cases behave, as well as
making it clear that blobs are immutable.

This fixes #75, fixes #99, and fixes #47.
It also lays the ground work to address w3c/webappsec-clear-site-date#49.

This also fixes #71.
mkruisselbrink added a commit that referenced this issue May 21, 2020
This redefines how blobs work by adding internal slots and hooks to
support Blob objects backed by various sources of data. By doing so this
tries to make more explicit how various edge cases behave, as well as
making it clear that blobs are immutable.

This fixes #75, fixes #99, and fixes #47.
It also lays the ground work to address w3c/webappsec-clear-site-date#49.

This also fixes #71.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants