On Tue, Mar 13, 2012 at 4:08 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Tue, Mar 13, 2012 at 3:58 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: >> On Tue, Mar 13, 2012 at 3:49 PM, Jonas Sicking <jo...@sicking.cc> wrote: >>> Hi All, >>> >>> Something that has come up a couple of times with content authors >>> lately has been the desire to convert an ArrayBuffer (or part thereof) >>> into a decoded string. Similarly being able to encode a string into an >>> ArrayBuffer (or part thereof). >>> >>> Something as simple as >>> >>> DOMString decode(ArrayBufferView source, DOMString encoding); >>> ArrayBufferView encode(DOMString source, DOMString encoding, >>> [optional] ArrayBufferView destination); >>> >>> would go a very long way. The question is where to stick these >>> functions. Internationalization doesn't have a obvious object we can >>> hang functions off of (unlike, for example crypto), and the above >>> names are much too generic to turn into global functions. >>> >>> Ideas/opinions/bikesheds? >> >> Python3 just defines str.encode and bytes.decode. Can we not do this >> with String.encode and ArrayBuffer.decode? > > Unfortunately I suspect getting anything added on the String object > will take a few years given that it's too late to get into ES6 (and in > any case I suspect adding ArrayBuffer dependencies to ES6 would be > controversial).
Like Ian said, I don't see anything particularly bad about the spec defining ArrayBuffers to define an ArrayBuffer-related method on String. There's no reason it has to be in the ES spec. ~TJ