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. >> > >> > >> > >
