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

[Juan Vuletich]

On 5/27/2019 4:56 AM, Luciano Notarfrancesco via Cuis-dev wrote:
> On Mon, May 27, 2019 at 5:27 AM Andres Valloud via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto: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.
>

These are ok for me. I'd add Float32Array and Float64Array. Also 
Int16PointArray and Int32PointArray. And of course, we'd made 
Stream('normalized access') and ByteArray('platform independent access') 
consistet with them.

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190527/d6cdf00f/attachment.html>