Frozen Date objects?

Rick Waldron waldron.rick at gmail.com
Wed Jul 17 13:04:23 PDT 2013


On Wed, Jul 17, 2013 at 3:06 PM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Wed, Jul 17, 2013 at 11:44 AM, Anne van Kesteren <annevk at annevk.nl>
> wrote:
> > Is it intentional that Date objects cannot be frozen?
> >
> > Use case: exposing the time of an event through a Date object while
> > not allowing fiddling with it.
>
> I was told frozen is only for properties. That doesn't seem ideal.
>
> Then IDL defines to always return a new Date object, which seems bad:
>
> % <video>.startDate != <video>.startDate
> true
>
> Is there a better way?
>


Can you explain why startDate was specified was a Date object? I've just
read the relevant portions of specification and I don't see any compelling
rationale. I did see the word "timestamp" used in a number of places, but
that contradicts the value type of event.timeStamp, which is |readonly
attribute DOMTimeStamp|—I make this comparison, because I would assume all
things described as "timestamp" would have the same value type. If
startDate were |readonly attribute DOMTimeStamp| (or more appropriately:
{[[Value]]: ..., [[Writable]]: false, [[Enumerable]]: true,
[[Configurable]]: false}), then user code could create a Date object if it
needed to or calculate the difference between some event's timeStamp and
the startDate, etc.


Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130717/42335f1e/attachment.html>


More information about the es-discuss mailing list