Binary data (ByteArray/ByteVector) proposal on public-script-coord
david-sarah at jacaranda.org
Thu Nov 5 22:14:09 PST 2009
Oliver Hunt wrote:
> On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:
>> Charles Jolley wrote:
>>> This looks like a good approach. I wonder if the Data/DataBuilder
>>> distinction could be handled better by using the Object.freeze()
>>> semantics. Even if the browser does not support freezing in the general
>>> sense yet, you could borrow the ideas for data.
>>> Probably the wrong API names, but here is the basic idea:
>>> -> returns a mutable form of the Data object
>>> Data.prototype.freeze() or Data.freeze(aDataObject)
>>> -> makes the Data object frozen if it is not frozen already
>>> -> returns the data object but pre-frozen. For Data object's already
>>> frozen can return "this"
>>> Data.prototype.frozen - true when frozen, false otherwise.
>> I don't know why we wouldn't just use Object.freeze. It is not
>> unreasonable to require support for the ES5 APIs as a prerequisite
>> for the Data type.
> 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.
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 292 bytes
Desc: OpenPGP digital signature
More information about the es-discuss