Make `ByteData` constructor/factory take a default endianness.

[lrhn]

Currently all methods of ByteData takes an optional endianness which defaults to Endianness.BIG_ENDIAN.
That's highly annoying when you are working with the class on a little-endian platform because you have to pass the optional argument to every method-call.

Remove BIG_ENDIAN as default value from methods, let them use the specified default (which can then default to big-endian).
This might be problematic on JavaScript because the underlying DataView class does not have a default-endianness field we can store it in, if we use that object directly instead of wrapping it.

[rakudrama]

dart2js notes.

I can confirm that dart2js does use DataView directly to represent ByteData.
When the Dart endianness argument is a constant, dart2js can inline and optimize the calls to what one would have written if programming in JavaScript.

The proposed idea might be acceptable for dart2js, but requires further investigation to determine if the resulting JavaScript code performs well.. There are two issues I anticipate:

1. I would be nervous about any scheme where the JavaScript-level endianness cannot be determined at the get/set method call sites. This limits the potential for the JavaScript engine to optimize the access. We might be able to have DataView.littleEndian and DataView.bigEndian constructors that return different implementation classes that bind the constant. If the receiver has one type, then inlining can proceed with the constant.

2. The current typed-data classes map directly to JavaScript classes. Once dart2js knows a class is part of the hierarchy, it can generate direct JavaScript property accesses for methods like buffer and lengthInBytes. Implementing any one of the classes as a wrapper has an impact on the others because it breaks the 1-1 mapping and makes the hierarchy mixed between 'native' and Dart types, which will lead to more uses of the more expensive 'getInterceptor' dynamic dispatch.

[lrhn]

Those were pretty much my conclusions too after reading the native typed-data library.
Anything we do will definitely come with a performance overhead.

On the other hand, the current API is highly annoying to use, and for the use cases I've personally had (unpacking some binary data format on Windows), performance wasn't really an issue.
I'm considering just putting a wrapper class in package:typed_data. You don't have to use it if you don't care, and if you do, you pay for it. I'd even be willing to call it LittleEndianByteData and not implement ByteData if that helps, as long as it's easy to use by itself.

[hacker1024]

Any progress on this?