- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 13 Mar 2012 16:32:25 -0700
On Tue, Mar 13, 2012 at 4:08 PM, Jonas Sicking <jonas at sicking.cc> wrote: > On Tue, Mar 13, 2012 at 3:58 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote: >> On Tue, Mar 13, 2012 at 3:49 PM, Jonas Sicking <jonas at 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
Received on Tuesday, 13 March 2012 16:32:25 UTC