- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 06 Nov 2009 01:24:06 -0800
- To: Charles Jolley <charles@sproutit.com>
- Cc: David-Sarah Hopwood <david-sarah@jacaranda.org>, public-script-coord@w3.org, es-discuss@mozilla.org
On Nov 5, 2009, at 5:14 PM, Charles Jolley wrote: > I hadn't thought about freeze affecting all other values on the > object. I agree that is not desirable. > > Still, having separate object types for mutable and immutable > objects introduces a new pattern to JS. Why not follow the pattern > used for freeze(), seal() and preventExtension()? Here's another > alternative as an example: > > Data.preventEdits(foo); > - makes editable data not editable > > Data.isEditable(foo); > - returns true if editable > > foo.copy(); > - returns a copy of foo, matching editable state. If foo is not > editable, may return foo > > foo.editableCopy(); > - returns an editable copy of foo, regardless of editable state > > Incidentally this API above could be implemented using separate > object types as you suggest by making DataBuilder an extension of > Data. This would be an implementation detail though rather than a > fundamental part of the API. I don't think that would work, unless Data.preventEdits(foo) returns a new value. I think the disadvantage of this design is that it puts all the mutation methods on immutable instances, where they are serve no purpose other than to throw when called. I think it is cleaner design for the immutable interface to lack mutation methods, rather than have mutation methods that always fail. I think designs where part of the normal workflow puts an object in a state where some methods always throw is poor OO design. It's true that ECMAScript has not historically had mutable/immutable pairs of types, but this is a common pattern in other languages, such as Objective-C (NSString vs. NSMutableString), Java (String vs. StringBuilder), various recent Lisp dialects (where there are often both mutable and immutable lists) and arguably event C++ (const string and string expose different sets of method). That being said, I can see how there is some value to aligning with the evolving ECMAScript pattern. Personally I think of Object.freeze as a tool for building new types that are meant to be immutable, or for exporting partially restricted facade interfaces, not as something one should be doing to random objects in the course of normal programming. Regards, Maciej
Received on Friday, 6 November 2009 09:24:46 UTC