Potential improvements to TypedData #55671
Labels
area-core-library
SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries.
library-typed-data
type-enhancement
A request for a change that isn't a bug
At this time, as[Typed]List view functions are associated to ByteBuffer, and get[Typed]Int values functions are associated to ByteData. (Some optimization requirement is behind this?)
To implement the most general interface, accept any sequence of bytes, one would do either:
Perhaps the most fitting would be to include the ByteData interface as a default interface in ByteBuffer. It seems more intuitive ByteBuffer holds a default get/set interface for accessing its contents, as well as contain the entirety of conversions. Homogenous list views can be views.
A work around for now
While lists constructed on the host platform and then read on the host platform is of no consequence to endianess. Handing network data would find a library implementation to be an asset.
something of the following nature, maybe not efficient, but correctness takes precedence.
Generic interface
Something as exemplified above using existing type markers, streamline dependencies which use multiple types.
Documentation duplication.
This does seem quite trivial, and I considered omitting the thought. But I suppose food for thought. While we pay regards to code duplication, for the human side of maintenance, interpretation.. mass amounts of repeated documentation text (perhaps can be condense to a centralized description), by the same principle, could be obfuscating key takeaways.
The text was updated successfully, but these errors were encountered: