[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 #29 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Arun from comment #28)
> 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.

Changing it from an object to a number is a much bigger change than changing it
from a property to a function.  If it's not enough of a problem to change it to
a function, it's definitely not enough of a problem to change the very data
type.

(I don't think it should be changed to a function at this point, because I
indeed don't think it's enough of a problem in an API already implemented
everywhere.)

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

*All* value-like JavaScript objects have unfortunate behavior for the ==
operator.  It's the same with dictionaries, Map, URL, and every other object
where people want to compare them as values.  This isn't a reason to not use
objects; it's just a JavaScript wart that we have to live with.

> 3. It's likely to be removed from WebIDL, so it's not a future-safe choice.

Date is not going away, no matter what WebIDL does.

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

Telling people that the points they're discussing are "not valid and not worth
debating" is dismissive and offensive.

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

Received on Wednesday, 4 December 2013 17:58:02 UTC