Re: [w3c/FileAPI] Readonly attributes without setters? (#126)

> Why is the name of the File object or instance important?
Perfect terminology says almost everything about underlying code. It is just an another way to differ good code from bad by using fast photographic perception. It may be important for many developers.

> What does .toNativeFile() do? Is the context JavaScript?
It executes File constructor with wrapped params when you actually need native file data object.

> If the requirement is to create a "file" that can be changed you can utilize data URL (data URI) data:[<mediatype>][;base64],<data>
It is not so complex. People wants to create a file, fix its name, extension, check mime type, manipulate its blob a bit using their own infrastructure with mutable instances or with other immutable objects. Nobody is using File class in the way it was designed. People uses their own classes and creates File only when they need its methods (or inherited methods). Noone wants to extend File. It is a complete interface failure.

> Note, technically, it is possible to mimic setting the actual name property of the File instance utilizing FormData(), append() and/or set() methods

```
var fd = new FormData();
var file = new File([1], "originalFileName.txt", {type:"text/plain"});
fd.append("fileName.txt", file);
console.log(file === [...fd][0][1]); // true
fd.set("fileName.txt", file, "newFileName.txt");
console.log(file === [...fd][0][1]); // false
```

It looks like FormData is the only class on this planet that uses File in the way it was designed. It recreates File on every sneeze. People will just change internal wrapper params and creates File only when they need it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/126#issuecomment-480986439