Binary Data - possible topic for joint session

[Ash Berlin]

On 8 Nov 2009, at 02:21, Maciej Stachowiak wrote:

>
> 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:
>>>
>>>> http://wiki.commonjs.org/wiki/Binary
>>>
>>> [snip]
>>
>> [snip]
>> 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


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

Mutable to immutable or immutable to mutable? Assuming the former, how  
do you handle the differences in API/behaviour? each function checks  
wether it is now immutable?

> On (2): I don't think a one-byte ByteString is ever useful, indexing  
> to get the byte value would be much more helpful.

Couldn't agree more with you here - if for whatever reason you do want  
a one-byte ByteString, there is always substr/substring. This is  
something that came up recently in IRC and prompted me to start  
looking at making changes to the proposal - I was going to do that  
next week, so this coming up now is very good timing.

> On (3), I think it's good for the mutable interface to be a strict  
> superset of the the immutable interface.

Seems like a reasonable thing to do.

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

Agreed - this was the other thing i noticed - e.g. sorting a ByteArray  
isn't really an operation that makes a whole lot of sense to my mind.

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

I'm not really bothered either way on this front, although 'Data' is  
much more likely to clash with existing code.

>
> Regards,
> Maciej
>

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.

-ash 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091108/676e451b/attachment.html>