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

> The API might not offer what you want from it.

I think that **File** is an object that **have** name, last modified, blob, etc. Rename operation on file should changes its name. Where is this method?

If your **File** do not offer this functionality why it's name is not **__FileInternal**?

> it can be a useful property that when you hand someone an object, they cannot change it from underneath you

It is functional programming method for protecting objects like **__FileInternal**, it is not suitable for **File**. You can't even imagine what amount of wrapper people have implemented around this API. Every new project comes with its own file/blob wrapper that does the same job - maintains properties inside.

> And conversely, as you noted, there are use cases better suited with more mutability.

So where is mutable wrapper around **__FileInternal**? What amount of years people have to wait before it will be available in all browsers? But nobody will actually replace existing wrappers in existing projects. Nobody will pay money for that job. These wrappers are a great monument for anyone who love functional programming so much, that any mutable API was just not implemented.

> As with all engineering, this is a trade-off

No need to any trade off here, just do not ignore mutable API. Please do not forget that you are working on API that people around planet will use.

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