Right now, ByteArray only supports [] for element access. I think byteAt
(like in ByteString) would be a reasonable addition, because it gives a
reasonable subset of operations that work identically on both ByteString
and ByteArray (effectively creating an interface of Binary).
Can I add that method to the Wiki?
On a related note, specifying some methods to be on Binary directly
might not hurt either.
Kind regards
Aristid Breitkreuz
Yeah, byteAt would be a fine edition, I think.
For the sake of genericity, I think that "charAt" was a mistake in the
earliest versions of JavaScript. A general purpose "get" function,
implemented wherever indexing [] is distinct from attribute selection,
would have been far more reusable and repurposable than a bunch of
functions named after the type that they return, like "charAt",
"byteAt", "numberAt", or so on. Since precedent is established, we
may as well run with "byteAt", but perhaps we can add the usual CRUD,
"get", "set", "has", and "del", to container types later. I would go
so far as to recommend more three-letter names for this purpose like
"cut" (get and del), and "put" (which would bump successive numeric
indicies for types where position is important, but otherwise be
identical to "set"). I know that we're not in the business of
invention here, but I think it would be good to keep these names and
purposes in the back of our minds.
> On a related note, specifying some methods to be on Binary directly
> might not hurt either.
Perhaps you could mention some ideas here. I'll start off with the
suggestion that "fromCharCodes" would be useful where applicable.
Kris Kowal
I will have many more suggestions, but these I shall ask now.
First, I have the following suggestion: moving ByteArray.prototype.join
to ByteString.join (as a constructor method). This would allow joining
Arrays of ByteStrings together to a single ByteString (interleaved with
the delimiter), arguably a more significant use case than joining the
bytes of a ByteArray to a ByteString, interleaved with delimiters.
I even think that having no join at all would be better than
ByteArray.prototype.join, because... just take into account that it
would join _single bytes_ with a delimiter. So
ByteArray([1,2,3]).join(ByteString[5]) becomes
ByteString([1,5,2,5,3])... ByteArray is NOT an Array of ByteStrings...
OK, second thing,
Kris Kowal schrieb:
What would that do? And do you mean Binary.fromCharCodes, or
Binary.prototype.fromCharCodes or do you even actually mean ByteString?
> First, I have the following suggestion: moving ByteArray.prototype.join
> to ByteString.join (as a constructor method). This would allow joining
> Arrays of ByteStrings together to a single ByteString (interleaved with
> the delimiter), arguably a more significant use case than joining the
> bytes of a ByteArray to a ByteString, interleaved with delimiters.
>
> I even think that having no join at all would be better than
> ByteArray.prototype.join, because... just take into account that it
> would join _single bytes_ with a delimiter. So
> ByteArray([1,2,3]).join(ByteString[5]) becomes
> ByteString([1,5,2,5,3])... ByteArray is NOT an Array of ByteStrings...
Sure. ByteArray is effectively a specialized array of numbers. I
wonder whether Array.prototype.join could be augmented to return a
ByteString if it is composed of ByteStrings and accepts a ByteString
as its delimiter argument, or return a ByteArray if the delimiter and
components are ByteArrays. Very good catch. It would be a stretch to
make ByteArray.prototype.join behave analogously to
Array.prototype.join (coercing its items and delimiter to ByteString.
How do you coerce a Number to a ByteString?)
>> [snip]
> What would that do? And do you mean Binary.fromCharCodes, or
> Binary.prototype.fromCharCodes or do you even actually mean ByteString?
I think String.fromCharCodes(arrayOfNumbers:Array) would be a good
complement to String.fromCharCode(charCode:Number). Thus:
String.fromCharCodes(string.charCodes()) and
String.fromCharCodes(array).charCodes() would complete a loop.
I also noticed when integrating Jack with ByteString that it's
sometimes handy to call object.toByteString(charset) without regard
for whether the object is a String or ByteString. Just as toString()
is idempotent, you would want toByteString(charset) to be idempotent.
To that end, I think we should consider adding
ByteString.prototype.toByteString(charset) as a third form of that
method that, like the no-arg form, returns itself, ignoring the
charset argument. Thus,
string.toByteString('utf-8').toByteString('utf-8') ==
string.toByteString('utf-8').
I am also in favor of a ByteString.prototype.toString(charset) form,
as an alias of ByteString.prorotype.decodeToString(charset).
Number.prorotype.toString([radix]) establishes a precedent in
JavaScript for that form. I also like that the specified
ByteString.prorotype.toString() form returns a "[ByteString {length}]"
representation.
That brings up the issue, should ByteString.prorotype.decodeToString()
without a charset argument use the system default charset? If no-one
objects, I would recommend that any proponent update the wiki.
https://wiki.mozilla.org/ServerJS/Binary/B
Another concern is that ByteString may not be comparable with == as
String is. If this is not implementable in all platforms, we should
add an equality comparison method. I recommend .eq(), .ne(), .lt(),
.le(), .gt(), and .ge(), for those purposes, in general, though I see
that the Java .equals() has some support in other APIs.
Kris Kowal
No! Not on Array! Changing the behaviour of Array.prototype.join seems
like a very very very stupid idea to me. It could break expectations in
all sort of ways, and it wouldn't really help clarity.
My proposal: join on the constructor of ByteString, taking an Array of
Binaries.
> [snip]
>
>
>>> [snip]
>>>
>> What would that do? And do you mean Binary.fromCharCodes, or
>> Binary.prototype.fromCharCodes or do you even actually mean ByteString?
>>
>
> I think String.fromCharCodes(arrayOfNumbers:Array) would be a good
> complement to String.fromCharCode(charCode:Number). Thus:
> String.fromCharCodes(string.charCodes()) and
> String.fromCharCodes(array).charCodes() would complete a loop.
>
I'm not sure how this is related to a module about bytes and binaries.
> I also noticed when integrating Jack with ByteString that it's
> sometimes handy to call object.toByteString(charset) without regard
> for whether the object is a String or ByteString. Just as toString()
> is idempotent, you would want toByteString(charset) to be idempotent.
> To that end, I think we should consider adding
> ByteString.prototype.toByteString(charset) as a third form of that
> method that, like the no-arg form, returns itself, ignoring the
> charset argument. Thus,
> string.toByteString('utf-8').toByteString('utf-8') ==
> string.toByteString('utf-8').
>
*blinks*
I'm not sure I follow, but it seems like it wouldn't create many problems.
> I am also in favor of a ByteString.prototype.toString(charset) form,
> as an alias of ByteString.prorotype.decodeToString(charset).
>
And I'm against that! I'm really really really really against
overloading method s in semantically unrelated ways. ToString is
specified to return a debug representation, then toString(charset)
should not do something _completely different_!
> Number.prorotype.toString([radix]) establishes a precedent in
> JavaScript for that form. I also like that the specified
> ByteString.prorotype.toString() form returns a "[ByteString {length}]"
> representation.
>
But Number.prototype.toString() without radix does a semantically
_closely_ related thing!
> That brings up the issue, should ByteString.prorotype.decodeToString()
> without a charset argument use the system default charset? If no-one
> objects, I would recommend that any proponent update the wiki.
>
If there should be a default, it should be specified by the spec.
> https://wiki.mozilla.org/ServerJS/Binary/B
>
> Another concern is that ByteString may not be comparable with == as
> String is. If this is not implementable in all platforms, we should
> add an equality comparison method. I recommend .eq(), .ne(), .lt(),
> .le(), .gt(), and .ge(), for those purposes, in general, though I see
> that the Java .equals() has some support in other APIs.
>
For symmetry reasons, I'd recommend Binary.eq/ne/lt/le/gt/ge and
Binary.compare(x1, x2), returning -1/0/1, all on the constructor of
Binary. x.eq(y) looks very weird IMHO.
We should drop the + operator from the spec, as it just can't be
implemented everywhere (I don't know if it actually can be implemented
anywhere, but it's certainly not possible with Spidermonkey).
And what does valueOf do?
Kris Kowal schrieb:
> Sure. ByteArray is effectively a specialized array of numbers. I
> wonder whether Array.prototype.join could be augmented to return a
> ByteString if it is composed of ByteStrings and accepts a ByteString
> as its delimiter argument, or return a ByteArray if the delimiter and
> components are ByteArrays.
I'm not sure how this is related to a module about bytes and binaries.
> I think String.fromCharCodes(arrayOfNumbers:Array) would be a good
> complement to String.fromCharCode(charCode:Number). Thus:
> String.fromCharCodes(string.charCodes()) and
> String.fromCharCodes(array).charCodes() would complete a loop.
>
> I also noticed when integrating Jack with ByteString that it's
> sometimes handy to call object.toByteString(charset) without regard
> for whether the object is a String or ByteString.
Just as toString()
> is idempotent, you would want toByteString(charset) to be idempotent.
> I am also in favor of a ByteString.prototype.toString(charset) form,
> as an alias of ByteString.prorotype.decodeToString(charset).
>
> Number.prorotype.toString([radix]) establishes a precedent in
> JavaScript for that form. I also like that the specified
> ByteString.prorotype.toString() form returns a "[ByteString {length}]"
> representation.
>
But Number.prototype.toString() without radix does a semantically
_closely_ related thing!
If there should be a default, it should be specified by the spec.
> That brings up the issue, should ByteString.prorotype.decodeToString()
> without a charset argument use the system default charset? If no-one
> objects, I would recommend that any proponent update the wiki.
>
> https://wiki.mozilla.org/ServerJS/Binary/B
>
> Another concern is that ByteString may not be comparable with == as
> String is. If this is not implementable in all platforms, we should
> add an equality comparison method. I recommend .eq(), .ne(), .lt(),
> .le(), .gt(), and .ge(), for those purposes, in general, though I see
> that the Java .equals() has some support in other APIs.
>
For symmetry reasons, I'd recommend Binary.eq/ne/lt/le/gt/ge and
Binary.compare(x1, x2), returning -1/0/1, all on the constructor of
Binary. x.eq(y) looks very weird IMHO.
We should drop the + operator from the spec, as it just can't be
implemented everywhere (I don't know if it actually can be implemented
anywhere, but it's certainly not possible with Spidermonkey).