[Bug 25343] Expose an isClosed property on Blob Objects

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

--- Comment #15 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Arun from comment #14)
> 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.

It's not a workaround, it's a straightforward coding pattern.  Something isn't
a use case needing a solution if there's already a perfectly reasonable way to
do it.

> 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? 

No, because if you set it to null, the data can't be freed until the object is
garbage collected.  The whole premise of close() is to allow memory and/or disk
space to be reclaimed without having to wait for GC.

> 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.

If you throw away the blob when you close it, there's no case where any other
code needs to know if the blob is closed, since you'll never give them one that
is.

It's not even clear to me why you'd want to check that.  Even if you're handed
a closed blob, you can just do whatever you were going to do, and if it's
closed it'll fail normally when you try to read it.  You already have the error
handling paths for that (since the read might fail for other reasons), and
adding an error check for something that you're already handling is just adding
new bug vectors and code paths to test.  It sounds like a premature
optimization...

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

Received on Wednesday, 7 May 2014 21:42:17 UTC