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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
