Binary Data - possible topic for joint session

[Maciej Stachowiak]

On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:

>
> On 6 Nov 2009, at 19:24, Brendan Eich wrote:
>
>> On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:
>>
>>> Just in case some of you weren't aware, the CommonJS group has  
>>> done quite a bit of work and (bikeshedding) on this topic. Here's  
>>> a link to the wiki:
>>>
>>> http://wiki.commonjs.org/wiki/Binary
>>>
>>> If nothing else there's quite a bit of prior art collected which  
>>> should inform the conversation. I know the Binary/B proposal has  
>>> the implementation momentum, but I don't know exactly what the  
>>> status is. I haven't been closely following the evolution of these  
>>> binary specs too closely but since it seems that nearly everyone  
>>> else from the group is off to jsconf.eu I figured I ought to toss  
>>> this out there.
>>
>> Thanks, I had forgotten about commonjs.org, having once paid better  
>> attention.
>>
>> Kris did a good job with Binary/B (although I do not see the point  
>> of the .get method additions) -- I didn't look at the other  
>> proposals yet.
>>
>> /be
>
> Binary/B feels largely right, but it has a few too many methods from  
> Array simply because Array had them for my taste, specifically  
> things like sort, reduce, shift, unshift etc.
>
> Conceptually: why would you want to sort an array of bytes? There  
> are certainly classes of operations that I think should just be done  
> via b.toArray().X rather than directly on the blob.
>
> As a community (CommonJS) we'd be more than happy to go forward with  
> a binary spec that came from (or at least has the blessing of) the  
> ES groups

Binary/B is the closest of the three proposals to mine, in that it has  
both mutable and immutable binary data containers. Here are a few key  
differences:

(1) Binary/B does not have a cheap way to convert from the immutable  
representation (ByteString) to the mutable representation (ByteArray)
(2) In Binary/B, Array-like index access to ByteString gives back one- 
byte ByteStrings instead of bytes, likely an over-literal copying of  
String
(3) There are some seemingly needless differences in the interfaces to  
ByteString and ByteArray that follow from modeling on String and Array
(4) Binary/B has many more operations available in the base proposal  
(including charset transcoding and a generous selection of String and  
Array methods)
(5) Different names - Data/DataBuilder vs. ByteString/ByteArray

My initial impression is that (1), (2) and (3) are all points on which  
my proposal is better. On (1): cheap conversion from mutable to  
immutable (DataBuilder.prototype.release() in my proposal) lets binary  
data objects be built up with a convenient mutation-based idiom, but  
then passed around as immutable objects thereafter. On (2): I don't  
think a one-byte ByteString is ever useful, indexing to get the byte  
value would be much more helpful. On (3), I think it's good for the  
mutable interface to be a strict superset of the the immutable  
interface.

(4) and (5) are all points where perhaps neither proposal is at the  
optimum yet. On (4), I suspect the sweet spot is somewhere between my  
spartan set of built-in operations and the very generous set in Binary/ 
B. On (5), I'm not sure either set of names is the best possible, and  
I'm certainly not stuck on my own proposed names.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091107/47f52728/attachment.html>