[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 #23 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Boris Zbarsky from comment #22)
> > you wouldn't change it for the ctor but not for the property
> 
> Why wouldn't you?  It makes a lot of sense to take millisecond timestamps in
> all places where you _accept_ dates.  Returning dates is more complicated in
> terms of object vs timestamp.

(I'm confused.  I read "why you *don't* think it should be used in the
constructor".  You actually asked "why you think it should be", but I didn't
say that.  I don't care if the ctor accepts *additional* types; what I'm
unconvinced by is the breaking change to the widely-implemented
File.lastModifiedDate.)

> > I meant the issue that while x > y and x < y work, x == y has a different
> > meaning and you need a separate method to test equality.
> 
> Yes, I understand that.  But that's only an issue because a new Date object
> is returned every time.  The sane thing to do would perhaps be to return a
> Date object that the caller cannot modify, but there is no such thing in ES
> right now.

No, the same thing happens if the user opens the same file in two places, or if
you clone the File object, or if you have two files with the same timestamp.

> > It's lame, but it's a language-level lameness that affects every class on the
> > platform, and it shouldn't be an argument against using objects.
> 
> It's an argument against _minting_ objects. It's not just == that's broken. 
> You get things like:
> 
>   foo.bar.x = "something";
>   alert(foo.bar.x); // hey, undefined
> 
> and people rightly start cursing the API designer.

Only because foo.bar is a property.  I think it's natural that a function
foo.getBar() gives a new object every time.

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

Received on Wednesday, 27 November 2013 15:07:46 UTC