- From: John Tamplin <jat@google.com>
- Date: Mon, 26 Mar 2012 21:21:34 -0400
On Mon, Mar 26, 2012 at 9:11 PM, Kenneth Russell <kbr at google.com> wrote: > The rationale for specifying the string encoding and decoding > functionality outside the typed array specification is to keep the > typed array spec small and easily implementable. The indexed property > getters and setters on the typed array views, and methods on DataView, > are designed to be implementable with a small amount of assembly code > in JavaScript engines. I'd strongly prefer to continue to design the > encoding/decoding functionality separately from the typed array views. > However, if the browser's don't all implement this, then you can't rely on it being there. In apps where you compile separately for each browser, you only pay the cost where the browser doesn't implement it (for example, in GWT we emulate DataView and Uint8ClampedArray where it is missing). Even then, you may have to include both versions and do runtime detection, such as when later versions of the browser include the functionality -- that may be worse than simply not using the API at all if you care more about code size than execution speed of encoding/decoding text. So, personally I think whatever gets the most browsers to completely implement it is better, whether that is being part of the typed arrays spec or separate. Logically, it seems to fit most directly in DataView. -- John A. Tamplin Software Engineer (GWT), Google
Received on Monday, 26 March 2012 18:21:34 UTC