<div dir="ltr"><div dir="ltr">On Mon, May 27, 2019 at 5:27 AM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">VW has a useful abstraction for this, the class UninterpretedBytes. <br>
While at first similar to a regular ByteArray, UninterpretedBytes <br>
implements things like shortAt:, doubleAt:put: and so on.  Now you need <br>
just one class instead of n.<br>
<br></blockquote><div> </div><div>That's a neat idea, maybe we can have that too. But I think it's different because the VM handles byte order conversion automatically for variable* classes on image loading, right? For me the reason to use for example a UInt16Array would be to make primitives that would work on arrays of uint16_t directly, without any conversion before or after primitive calls to avoid wasting any cpu cycles. Does UninterpretedBytes also fix byte ordering on image loading? The old ShortIntegerArray and subclasses do fix byte ordering on loading but they carry this "glitch" that their size must always be even...<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If those selectors could be named after standard types of fixed length <br>
too (like 'uintptr_t'), then great because e.g. nobody says what the <br>
size of a C 'long' is.<br></blockquote><div><br></div><div>Yes, I don't really like those names but maybe that's the best option, most unambiguous and familiar to most people. For example UInt16Array, Int16Array, UInt32Array, Int32Array, UInt64Array, Int64Array? I wouldn't want to rename ByteArray to UInt8Array tho, I think.</div><br></div></div>