add: struct BytesView, trait ByteView & binary representation methods. #347
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a direct port of practice-tested
loneoutpost/core-extra/representation
mooncake.Contents
This PR includes 3 main parts
trait ByteView
&trait ByteMutView
to indicateByte
sequences from any data source, read-only or writable.struct BytesView
which indicates a read-and-writableByte
sequence sliced from aBytes
.Int
,Int64
andDouble
supporting any specified endianness.Solid and complete tests and documentations provided.
Competing PRs
This PR is competing to #328 and #329.
Concrete
struct BytesView
...is similar but different from #328. This PR makes the output type
Byte
instead ofInt
.Abstractions
trait ByteView
&trait ByteMutView
... are new. Since
Byte
sequence can come from various sources (memory, disk, network...), I think adding such abstractions tocore
is critical for supporting various programs.The whole
@mem
module_ appeared in #329... which includes abstractions
Loadable
(read from bytes) orStorable
(write into bytes) and implementations for primitive types, are removed.This PR made these R/W operations (between primitive types and
Byte
views) simple methods in the primitive types' package, for the following reasons:Loadable
/Storable
is actually an abstraction of serialization/deserialization(serde). As the practices from Rust community, serde is more appropriate to appear as a 3rd party package instead of a core feature.@mem
is more suggested to be reserved for usages dealing with real memory.Notes
This PR somewhats implements #341.