[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 #21 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Boris Zbarsky from comment #20)
> Glenn, I would be very interested in why you think Date should be used in
> the _constructor_.  Or do we agree that using a numeric timestamp there is
> maximally compatible (and still allows callers to pass in a Date)?

We're talking about changing it for both--you wouldn't change it for the ctor
but not for the property.  I don't think using a number is bad, but I think the
reasons for changing it now, on a feature that appears to already be
implemented in Chrome, Firefox and IE, are at least poorly established.  (You
could add a scalar version of the property without removing the Date version,
but that seems even less worthwhile.)

> As for returning a value, you're right that there is a problem common to a
> number of JS objects that have internal state but you don't want the page to
> mutate.

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

I think the mutability issue is less serious: returning a new object isn't a
big deal.  It would be better to have a function instead of a property in that
case, but I don't think it'd be worth changing it at this point.

> Note that this is not a problem for dictionaries (e.g. you could
> return a frozen one), but _is_ a problem for Map and Date, because those
> can't be meaningfully made immutable.  One could, of course, return proxies
> that disallow the mutation methods... There are a bunch of open issues here,
> and I'd welcome your input on solving them, on public-script-coord.

I'd expect an immutable Date to be a base class of Date that simply doesn't
have the mutation methods in the first place.  I thought about that a bit, but
I'm not sure it's worth it compared to just returning a new object each time.

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

Received on Wednesday, 27 November 2013 03:41:55 UTC