[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 #30 from Arun <arun@mozilla.com> ---
(In reply to Glenn Maynard from comment #29)
> (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.)


I think we agree that it shouldn't be changed to a function.  I think allowing
a Date in the constructor, even if as an incidental benefit, is a good thing. 
Also, the integer can be read with a Date, so it isn't a huge leap IMHO, though
perhaps more lines of code.  Instructive code snippets might help the spec
here, both for the constructor and for reading a date that's an integer.

It would be nice if separately we could find a freezable date abstraction, but
that takes us out of the scope of the File API.


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


Of course this is an issue with JS objects in general, but I think this is a
good reason to use caution when specifying a readonly property that is supposed
to ultimately yield a measurable value.  And of course, we can't avoid the use
of value-like JS objects altogether, but we should make reasonable guarantees
of logical behavior when specifying attributes.

Right now, the particularly problematic behavior is for *Date.*  We have this
problem in general, but it's with Date that we see this most acutely, when in
fact the value for unmodified files should behave like comparable integers that
test true.


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


This is true, but we can avoid the introduction of instabilities by trying to
do the right thing.  Enough people seem to agree with this general technical
direction (including some implementers, judging from the es-discuss thread),
though the point of whether this is too late breaking a change is still valid.


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


I think we can reasonably disagree, and (once again) apologize if my tone isn't
reasonable.  In Comment 13 you were just about on board with using numbers
("...if numbers are used..."), which is what prompted me to close this bug in
the first place (sure, you may have been an advocate for seconds-since-epoch
and the use of double, but that's already agreement with the change).

I agreed with your point about this being a late-breaking change, which is why
I reopened this.  I will close it modulo feedback on the listserv from
implementers (or feedback here).

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

Received on Wednesday, 4 December 2013 19:04:18 UTC