W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 06 Nov 2009 01:24:06 -0800
Cc: David-Sarah Hopwood <david-sarah@jacaranda.org>, public-script-coord@w3.org, es-discuss@mozilla.org
Message-id: <078F4BB4-33E3-4DCF-865D-58E29AFA3592@apple.com>
To: Charles Jolley <charles@sproutit.com>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC