Problem

Xojo apparently has Int8, Int16 and Int32 types, and you can take 1, 2 or 4 bytes from a MemoryBlock and convert to and from those types.
I assume you left these conversions off at least for now because Objo doesn't have those types.
I further assume you'd rather not provide conversions that might be cruft that no one uses IF you plan to implement those later.

Proposed Solution

It would be nice to be able to convert Integer to and from 1, 2, 4 and 8 byte MemoryBlock or slices of that size. I don't think these would be rendered useless if you had more detailed type support later. It would just be another option that one could use depending on need.

These would probably be something like Integer.Parse(memorySlice) that would accept the above-mentioned sizes and convert accordingly to an Integer. In the other direction, Integer.ToMemory(width As Integer) would convert an Integer back to the desired width MemoryBlock slice. Obviously it would throw an exception if out of range, e.g., anything other than 0-255 for one byte, -32768 to 32767 for 2 bytes, etc.

I guess this also raises the specter of determining the "endian-ness" of a MemoryBlock. Xojo defaults to LittleEndian for all platforms and I've personally never had a need to deal with BigEndian so I would be fine with just LittleEndian as I presume it is now; you don't support the option for BigEndian at present and as far as I'm concerned that's fine unless going either way is way less of a pain than I suspect it is.

Another issue is signed vs unsigned integers. I think it's probably best to assume 2, 4 and 8 byte integers encode signed values for now. I haven't personally needed unsigned. I don't think Xojo supports them except that I would suppose it assumes 8 bit values are unsigned in the range 0-255.

Finally there's the issue of supporting doubles and CStrings and other common binary types of strings ... for simplicity I would suggest just starting with integers.

Example Workflow

Alternatives Considered

It's not hard to decode them one byte at a time in ObjoBasic, it would just be slower compared to native support for a common need like this, and I'd hate to get such an implementation into a hot path.
Later, when .NET interop or other external libs are supported, one could go that route to get this functionality.
I do understand you have to balance supporting a larger "surface" of features vs how often they would be used or where maybe 3rd party support would be sufficient. There's also something to be said for doing it the same as Xojo or at least as similar as possible, but I doubt you want to create 3 new integer types just to support this functionality (even though I'd ultimately like to see Int32 or whatever you'd call it, as a first class type; it would be more performant for most loop counters, etc).

Who Would This Help?

People reading / writing binary data