[Bug 23853] Please clarify the interpretation of the WebIDL undefined Date in the File constructor

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

--- Comment #28 from Arun <arun@mozilla.com> ---
(In reply to Glenn Maynard from comment #27)
> There have been no arguments made for why Date is a bad API (only that File
> should have put it on a function rather than a property), and "because
> someone else says so" isn't close to good enough for changing an API that's
> already deployed in every major browser.


Date is a bad choice for a readonly attribute, and using it in the File API for
a readonly attribute is a bug.  

1. It makes the readonly nature of an attribute suspect -- this makes it a bad
API choice for a readonly attribute.  We shouldn't change it to a function now
since I think that's too much API for too little value.
2. It returns new values each time, which leads to false tests of equality,
which is illogical.  This makes it a bad API choice for a readonly attribute.
3. It's likely to be removed from WebIDL, so it's not a future-safe choice.

In retrospect I (we) should have pushed harder on the choice to make the
attribute return a Date, but... hindsight is etc. etc.

I think the real debate is whether it's too late a breaking change for
implementers to rally behind.  That's the only point worth arguing, honestly.


> The most likely result is that we end up with *both* properties on File, and
> that's the worst possible outcome.  (Whatever things you don't like about
> the current API would remain, so adding a second property doesn't help at
> all.)

Agreed.  I'd MUCH rather remove lastModifiedDate and expunge it from the spec.
altogether.  Since the only valid point worth debating is whether that's too
late a change, out of caution I reopened this bug and polled the listserv. 
Implementers are encouraged to respond soon.

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

Received on Wednesday, 4 December 2013 17:26:48 UTC