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: >>> >>> Data.prototype.copy() >>> -> 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 >>> >>> Data.prototype.frozenCopy() >>> -> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
