Binary Data - possible topic for joint session

[Ash Berlin]

On Sat, 07 Nov 2009 19:17:48 -0800, Maciej Stachowiak 
wrote:


> Mutable to immutable. Immutable to mutable has to copy (or at least 
> copy-on-write).
> 
> My proposal does it like this (where DataBuilder is the mutable 
> variant and Data is the immutable):
> 
> DataBuilder.prototype.release()
> 
> Return a new Data with the same length and the same byte values 
> as the DataBuilder passed as the this value. At the same time, the 
> DataBuilder is reset to length 0.
> 
> Because the DataBuilder is reset to empty, the implementation can 
> "steal" its underlying buffer for the new Data object, thus converting 
> to immutable without a full copy. This matches the common pattern of 
> assembling a new piece of binary data with mutation, then handing it 
> out to possibly multiple other pieces of code as immutable.
> 

Seems like a good idea, but is this a case of baking too much
implementation detail in the spec?


> Yes, Brendan made this point and presented some good evidence in that 
> direction. I think 'Data' doesn't work but 'Binary' or 'BinData' might.

Yay naming bike-shedding. Perhaps postponing the naming until later on in
the process once the rest of the API is more concrete? 

>> Something worth bearing in mind is that Binary/B is implemented in 2 
>> or 3 CommonJS platforms already, but I don't think any one is 
>> particularly attached to the behaviour so long as what comes out 
>> isn't wildly different.
> 
> What kind of differences do you think they would tolerate? Renaming 
> the classes? Dropping/changing some methods?

I haven't checked with anyone, but so long as there is a clear migration
path I can't see anyone complaining too vocally.