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