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

[Charles Jolley]

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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss