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