[Bug 25343] Expose an isClosed property on Blob Objects

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25343

--- Comment #14 from Arun <arun@mozilla.com> ---
(In reply to Glenn Maynard from comment #13)
> Please explain why you feel strongly that it should be there, despite the
> fact that you can't come up with any use cases.

First, it's not true that there aren't any use cases. You've merely provided a
(reasonable) workaround; it doesn't necessarily invalidate the use case. It is
still a use case that could make use of both close() and a test for closure.

Any question about a property like .isClosed can equally be asked about close()
-- why have a close() at all, if explicit reference nulling can be availed of?
The intent was to allow web developers a chance to manage their applications'
use of memory by marking Blobs disabled for memory intensive operations (e.g.
read). But couldn't they just as easily set to null or work with loss of
reference explicitly? This might cause network errors as well, and return
failure on reads, which are desired in this case. A good history of close() is
in Bug 16952; in particular, from Bug 16952 Comment 17, is this:

"The thing is that a Blob can generally be passed around through a lot of parts
of a code-base due to it's mostly-readonly nature.

This could mean that just because part of the code closes a Blob, doesn't
always mean that another part of the code which has a reference to the same
Blob, is always aware."

While we can rely on operation failure, I think the web developer should be
able to test before calling an operation. And, note that some operations don't
fail, like slice() -- it merely coins a closed Blob. 

If we introduce a capability with this kind of semantics, we should allow a web
developer to test for it, no, and not merely keep it internal? A different part
of the code may need to be made aware of the closure from the explicit calling
code.

Forcing a full reference loss is radical and stops all operations. Here, we
only stop reading; it's been suggested that a different bug might be filed to
allow the structured clone algorithm to proceed unimpeded. So since we have a
mix of operations that might continue as well as that might fail (because of
the distaste for throwing), then we should have a property that allows a web
developer a chance to check. That's why I feel strongly.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 7 May 2014 17:49:05 UTC