Frozen Date objects?

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Jul 17 13:30:11 PDT 2013


On Jul 17, 2013, at 12:41 PM, Brendan Eich wrote:

> Domenic Denicola wrote:
>> From: Anne van Kesteren [annevk at annevk.nl]
>>> Is there a better way?
>> 
>> ```
>> <video>.startDate() !==<video>.startDate()
>> ```
> 
> Using a method instead of a getter is better style where the result is generated on each call, but doesn't get at Anne's question.
> 
> IIRC Mark has thoughts about freezing of Date objects, since inability to freeze Date.prototype leaves a side channel.

Didn't we discuss making the [[DateValue]] immutable when a Date object is non-extensible?  I see this isn't currently in the ES6 draft.  Also, thinking about it now, that seems like quite a one-off hack.

One of the ES6 "issues" I have on the agenda for the next TC39 meeting is "Does Object.freeze need an extensibility hook?"

This issue was motivated by the fact that 
      Object.freeze([1,2,3])
gives you a read-only array, while
      Object.freeze(new Float64Array([1,2,3]))
at best gives you a typed array instance with writable elements (some existing implementations actually throw when you try to freeze a typed array).

This seems like a surprising inconsistency if you are thinking in terms of array abstractions. If Object.freeze is how you make an "array" immutable why shouldn't it work on typed arrays?  Isn't whether elements are implemented as properties or as slots in a buffer just an implementation detail from the perspective of the abstraction.

This is similar to the Date issue.

On possibility is to add an extensibility hook to Object.freeze.  It could be specified to call a @@freeze method on the target object (if it has one).  A hook method could then take any appropriate action, such as setting an internal immutable flag.

Allen


More information about the es-discuss mailing list