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.
-Charles
On Nov 5, 2009, at 4:55 PM, Maciej Stachowiak wrote:
>
> Using the freeze pattern is an interesting possibility that I hadn't
> considered. Tentatively, I think having separate types for mutable
> and immutable is better than using freeze(). Here are my reasons:
>
> - It seems like it may be useful to have an immutable Data (one that
> doesn't let you change the buffer) but which is not in other
> respects frozen.
> - The immutable type would not only freeze the types, but also not
> provide functioning mutation methods. I think it is cleaner design
> for the immutable form of the object to lack mutation methods
> entirely, rather than to have neutered mutation methods that always
> fail or always throw.
>
> That being said, I think it's an alternative worth considering.
>
> Is there enough interest in this topic in general to spend some of
> the joint TC-39/HTML/WebApps session on it?
>
> Regards,
> Maciej
>
> 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.
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss