On Wed, Jul 17, 2013 at 3:06 PM, Anne van Kesteren <[email protected]> wrote:
> On Wed, Jul 17, 2013 at 11:44 AM, Anne van Kesteren <[email protected]> > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
