- From: Oliver Hunt <oliver@apple.com>
- Date: Thu, 5 Nov 2009 16:13:46 -0800
- To: David-Sarah Hopwood <david-sarah@jacaranda.org>
- Cc: es-discuss@mozilla.org, public-script-coord@w3.org
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 (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. Basically i think we're attempting to conflate the ES object with the data wrapped by the ES object. --Oliver > > -- > David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
Received on Friday, 6 November 2009 00:15:05 UTC