Binary Data - possible topic for joint session
brendan at mozilla.com
Fri Nov 6 10:21:07 PST 2009
On Nov 6, 2009, at 9:18 AM, Maciej Stachowiak wrote:
> On Nov 6, 2009, at 8:26 AM, Brendan Eich wrote:
> Indeed, I'd rather not propose APIs like that in the initial version
> (though I think eventually we may want a way to copy sequences of
> 16-, 32-bit or 64-bit values swapping from network byte order to
> host byte order or vice versa to make it practical to interpret
> popular binary formats.
Could be -- I agree we should defer.
> However, I think a common use case for binary data is to pass it
> around for point A to point B, without unpacking the internals at
> all, just as for strings. For example, you may read a file in binary
> form, pass the binary data off to a Worker, and then have the Worker
> upload it to a server. This is part of why I leaned towards a name
> that does not overly emphasize the byte sequence nature.
Yet the minimal API will give byte-element access, not variable-length
bit string or any other such access. Concrete beats abstract every
time in this level of discourse, in my experience.
>> Therefore I think a concrete name such as ByteVector or ByteArray
>> is better, all else equal.
>> Moreover a name such as ByteVector is much easier to inject as a
>> global property. No hits for the obvious function and var forms of
>> it, one hit for ByteArray:
> Some other possible names (based in part on some other binary data
> proposals that I've seen):
These look free of conflicts from some quick codesearch'ing --
ByteString is good, better than ByteVector if we do not allow bytes to
If any of these involve detection, we probably can't use Binary. I did
not look further, but suggest we eliminate candidate names that are
already in use according to Google codesearch.
A few hits:
> Good topic for in-person discussion maybe?
More information about the es-discuss