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

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.
>

Received on Friday, 6 November 2009 00:56:24 UTC