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
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).
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.
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.
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?
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.
Activity
mkruisselbrink commentedon Mar 31, 2017
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 commentedon 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 commentedon Apr 3, 2017
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 commentedon Apr 8, 2019
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 commentedon Apr 8, 2019
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 commentedon Apr 8, 2019
@andrew-aladev If
toNative()only sets thenameproperty of theFileobjectFormDataset()method can be utilized #126 (comment)Rewrite a lot of the internals of Blobs to make reading more explicit.
Rewrite a lot of the internals of Blobs to make reading more explicit.