Freezing object properties or array values, whilst keeping them extensible

David Bruant bruant.d at
Tue Jun 4 11:43:50 PDT 2013

Le 04/06/2013 11:24, Andy Earnshaw a écrit :
>     I'm not sure I understand what you're saying here. Do you want to
>     return the same or a different object? For sure, your caller will
>     know if you returned a different object (because it can compare
>     the argument and the return value)
> Well, the plan was for whatever worked, really.  If I could have 
> created a new array that I had more control over, then that would 
> simply be the standard behaviour for that function.
In ES6, you can create a proxy.

>     Your use case suggests the need for a well-encapsulated weakmap,
>     no need for new constructs, I think. We have enough low-level
>     control over object I feel.
> A weakmap wouldn't have really done the trick because the external 
> code could have modified the contents of the array before passing it back.
The external code that gave you the array or one you give the array to? 
In a nutshell, whoever creates something has initially all power over it 
and can decide to share full or partial (or no) authority.
Can you provide more details about your use case?

> The weakmap would help in identifying a previously prepared array, 
> sure, but it wouldn't keep the integrity of it intact.  However, it 
> seems that all this is pretty much a moot point, Array.freeze would 
> just be an easier way to do it than iterating over the array and 
> changing all the elements to {writable:false, enumerable:true, 
> configurable:false} as well, but I can understand not wanting to add 
> simple stuff like this in.
Indeed. A concern is where to draw the line between what's in the 
language and what isn't. In any case, nothing stops you from adding 
Array.freeze yourself... but please don't add it to the built-in Array ;-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list