On Nov 7, 2009, at 6:53 PM, Ash Berlin wrote:
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?
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.
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.
I'm glad we agree on these two points.
(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.
Yep. I'm not even sure things like map(), filter() or reduce() are
likely to work well. My own preference is to start the API very small,
and add incrementally based on demonstrated need and clearly
articulated use cases.
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.
Yes, Brendan made this point and presented some good evidence in that
direction. I think 'Data' doesn't work but 'Binary' or 'BinData' might.
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?
Regards,
Maciej
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
