The natural conclusion I was thinking was like using ["x", "y",
"z"].join(""); rather than "x" + "y" + "z", where you can size the
result once without having to make repeated copies in realloc (so it
can be faster for large or numerous inputs). Which is not
incompatible with your suggestion. Since it is blobs which are being
constructed, though, it would be reasonable to be pedantic about the
types accepted.
-scott
[Sorry if that wasn't sensible JavaScript syntax!]
On Fri, Mar 13, 2009 at 1:25 PM, Michael Nordman <[email protected]> wrote:
> Taking this to the natural conclusion... append([1, "two", blob, ['fee',
> 'fi', 'fo', 4]])... could have the obvious meaning
> On Fri, Mar 13, 2009 at 12:14 PM, Michael Nordman <[email protected]>
> wrote:
>>
>>
>> On Fri, Mar 13, 2009 at 11:33 AM, Scott Hess <[email protected]> wrote:
>>>
>>> That could be orthogonal, array of ints appends each byte, array of
>>> strings appends all the strings, array of blobs appends all the blobs?
>>
>> Thats reasonable.
>>
>>>
>>> -scott
>>>
>>>
>>> On Fri, Mar 13, 2009 at 11:13 AM, Michael Nordman <[email protected]>
>>> wrote:
>>> > Maybe an array containing interger values... var bytes = [0,1,2,3,4];
>>> >
>>> > We could overload .append(bytes) to mean append each element in the
>>> > array as
>>> > a byte... and fail if any elements are non integer values or are > 255
>>> > or <
>>> > 0
>>> >
>>> > Agreed, getByte() on a blob would be nice for symmetry.
>>> >
>>> > On Thu, Mar 12, 2009 at 9:56 PM, Nigel Tao <[email protected]> wrote:
>>> >>
>>> >> Looking at the BlobBuilder API again...
>>> >>
>>> >> The code, as is, defines an blobBuilder.append method that takes
>>> >> either a string, or a blob. With the string version (which is always
>>> >> interpreted as UTF-8), I can append any byte in the range 0-127 (which
>>> >> satisfies the multi-part form use case), but not necessarily a byte in
>>> >> the range 128-255.
>>> >>
>>> >> Should we also let the append method take an integer (as well as
>>> >> either a string or a blob, as it currently does), and interpret that
>>> >> as meaning appending the byte (arg & 0xFF)? Another option is having
>>> >> three methods appendBlob, appendStringUtf8 and appendByte, but I
>>> >> prefer the overloaded append method.
>>> >>
>>> >> Also, if we are allowing appending bytes, should we add a
>>> >> getByte(int64 index) method to a Gears blob? Whilst I don't have an
>>> >> immediate need for such an API, I think the symmetry seems like a
>>> >> natural conclusion from having appendByte, and might also allow for
>>> >> some interesting experiments, such as client-side SHA-1 calculations.
>>> >
>>> >
>>
>
>
