[Cuis-dev] [Integrated] Should we rename these? Re: support for variable indexable subclasses of 8/16/32/64 bits

[Luciano Notarfrancesco]

On Mon, May 27, 2019 at 5:27 AM Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> VW has a useful abstraction for this, the class UninterpretedBytes.
> While at first similar to a regular ByteArray, UninterpretedBytes
> implements things like shortAt:, doubleAt:put: and so on.  Now you need
> just one class instead of n.
>
>
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...

If those selectors could be named after standard types of fixed length
> too (like 'uintptr_t'), then great because e.g. nobody says what the
> size of a C 'long' is.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190527/a9eeeb9e/attachment.html>