[Bug 23479] File Constructor and Blob Constructor should have same signature

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

Glenn Maynard <glenn@zewt.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glenn@zewt.org

--- Comment #2 from Glenn Maynard <glenn@zewt.org> ---
Dictionary arguments are for optional parameters, so fileName doesn't belong in
there unless you want to make it optional.  It does seem like it should be
optional, if only because it's harmless and will make more sense if File gains
other properties.

It's a little weird that you have to specify File.type by setting it on another
Blob first, and the first thing I tried with File's ctor was new File(["foo"]),
so it's definitely a bit odd.  I guess it's so you don't have to manually copy
every property on the Blob if all you're doing is taking a Blob and attaching a
filename to it: new File([blob], {type: blob.type}) is pretty awkward,
especially as more properties are added to Blob.

You'd have the same problem if all you were doing was modifying a property,
though, at least if there were any properties to replace.  For example, if it
was possible to specify lastModifiedDate (it's odd that it's not), you'd have
to specify every other property on the old File, eg. new File([oldFile],
oldFile.name, {every property ..., lastModifiedDate: date}]).  That wouldn't be
good.

I think there's something off about the constructor pattern here that won't
really surface until Blob and/or File have one or two more properties, since
you shouldn't need to carefully respecify every property to create a Blob or
File with just one property changed.  I don't know off-hand what a good fix
would be, though.

(FWIW, I think the File class shouldn't exist, and its properties should just
be on Blob.  The separation doesn't help anything since there's no *functional*
difference between the two, so it just makes things more complicated.)

(In reply to Jonas Sicking from comment #1)
> Sorry, sent original email to the wrong email list.
> 
> The waste I'm referring to is both in terms of code size and in terms of
> memory.
> 
> The extra JS object isn't a big deal, but it will keep the contained data
> alive even if the File object is GCed or .close()ed.

There shouldn't be a memory penalty.  If you do this:

var b = new Blob(["hello");
for(var i = 0; i < 1000000; ++i)
    b = new File(b, "hello.txt");

then the result (after GC) shouldn't take more memory than going through the
loop just once.  Creating each new File should reference the underlying data,
which isn't changing--this shouldn't result in a million nested File objects. 
In other words, the resulting File should internally look like File(["hello"]),
and not File([File([File([File([Blob(["hello"])])])])]).

Data staying alive after .close() is nothing new.  If you want to be able to
close a blob, you explicitly need to close every copy you've ever made, since
.close() explicitly doesn't apply to slices.  That probably makes .slice() very
hard to use reliably, but that's a separate discussion...

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

Received on Friday, 11 October 2013 00:53:22 UTC