Closed aejenk closed 5 years ago
Update explanation: In MmapMut
you can use get_mut
to retrieve a slice of mutable bytes, however this would limit the capabilities of a Mutation.
A Mutation
should mutate the file, not a chunk. The reasoning behind this is that some mutations can extend beyond the chunk. For example, if I have:
[1,2,3,4,5,6]
...and the slice is 1,2,3
- however the Mutation acts by, for example, adding this chunk to the next chunk, the expected value would be this:
[1,2,3,5,7,9]
Another option is that the Mutation
might wrap around from the end of the file, back to the beginning. Hence, why the whole map needs to be passed.
An alternative to this is passing a mutable reference to the mapped file - but this should be tested for practicality. If it works, however, then it is preferred.
Update to issue: the mutate
function will still contain two arguments, the first one being the data, however the second one would become another type of custom enum - HashMap<&str, OptionVal>
OptionVal
would be an enum with the following values:
enum OptionVal {
OString(String)
OInt(isize)
OBool(bool)
OArray(Vec<OptionVal>)
}
This way, custom objects can be implemented dynamically. Each String
name would map onto an OptionVal
. containing the values specified.
Thanks to @LunarLambda for this idea!
Mutation
should be added as a trait, with amutate
function.This function should take two parameters -MmapMut
, and a Vector ofMutOption
.MutOption
is an enum specifying options of how the mutation should be done. For example,ChunkSize(u64)
would be an option specifying how large each chunk to mutate is.Mutations
may use the requiredMutOptions
and ignore the rest.A helper function
process_options
can be made to retrieve the relevant options and return them in a struct, wrapped around aResult
.Ok
would contain the parsed options, andErr
would mean that required options are not present. This is optional however.