[Bug 25343] Expose an isClosed property on Blob Objects

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

Jonas Sicking <jonas@sicking.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonas@sicking.cc

--- Comment #16 from Jonas Sicking <jonas@sicking.cc> ---
I don't have a strong opinion here.

However I'll note that keeping internal hidden state in APIs generally always
result in that we get asked to expose that state because it's easier in some
web developer's architecture.

I.e. while it's easy for us to say that you could always do

someObj.the_blob.close();
someObj.the_blob = null;

things might not be as simple in all web apps. I.e. maybe there might be a
whole host of "someObj" objects that all point to the same blob. Tracking all
of them down might add considerable complexity.

This was the same reason that we added IDBObjectStore.name. In theory it's
always quite easy to track the name of an object store, since the only way you
can get a reference to it in the first place is by knowing its name and calling
transaction.objectStore(name). And the implementation will basically have to
track the name internally in the object anyway in order to implement it's
functionality, like IDBObjectStore.get().

So since the spec basically requires that the name is kept in the object, and
the name does significantly affect the object's behavior, exposing it seemed
like a very low cost and of potential value to authors.


I think the same thing applies here. Any reasonable implementation of Blob is
going to track internally if .close() has been called or not. Exposing it is
bound to have very low implementation cost. I hate the idea that not exposing
it would cause developers to do *any* extra work in order to work around the
shortcoming. I'd much rather that they spend the time developing awesome
features for users.

Developers might definitely be able to work around not having .isClosed
available. But what's the value of asking them to given the extremely low
implementation cost?


Similarly, I don't see that the implementation cost of this feature could go up
in the future. I.e. I don't see any risk that this would prevent us from making
any changes to the API in the future, or that it would prevent any
implementation strategy for developers.

If there was any concern that adding .isClosed would have a higher cost in the
future then I'd definitely agree that we should wait for stronger use cases
before adding it.

Is there any such concern here?

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

Received on Thursday, 8 May 2014 20:53:39 UTC