Binary data (ByteArray/ByteVector) proposal on public-script-coord

David-Sarah Hopwood david-sarah at
Thu Nov 5 23:14:42 PST 2009

David-Sarah Hopwood wrote:
> Oliver Hunt wrote:
>> On Nov 5, 2009, at 10:14 PM, David-Sarah Hopwood wrote:
>>> Oliver Hunt wrote:
>>>> I disagree here -- i believe mutable vs. immutable data is different
>>>> from unfrozen and frozen objects [...]
>>> Why? What would the hypothetical Data.prototype.freeze do that would be
>>> different to applying Object.freeze to a Data object?
>>>> (though i agree that the function names
>>>> freeze and frozen are just asking for problems in conjunction with ES5
>>>> :D ).  There are plenty of times where I would want to provide immutable
>>>> data (the UA sharing content, etc), but i may still want to modify the
>>>> object itself.
>>> Oh, you mean that you want *read-only* Data objects backed by a mutable
>>> array. That is not the same thing as an immutable (or "frozen") Data
>>> object.
>> No, the issue here is that Charles has conflated object freezing with
>> immutable data,
> That isn't conflation; they're the same.

Sorry, I understand what you meant now.

An object could of course have immutable data properties but other
properties that are mutable. But that can be achieved already using
Object.defineProperties, if it were considered useful. I don't see it
as particularly useful, given that you can achieve a similar effect
more simply by using a mutable "record" object that has an immutable
Data object as one of its properties.

Remember, we have Object.freeze regardless. Therefore, if we have
a mutable byte array, then applying Object.freeze to it yields an
immutable byte array. So adding an extra type to represent immutable
byte arrays is redundant.

David-Sarah Hopwood  ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the es-discuss mailing list