[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 2:27 AM, Andres Valloud via Cuis-dev wrote:
> Why should accessing bytes differently need copying the bytes into a 
> different class?  The bytes won't change, no?
>
> 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.

We already have that. See ByteArray's 'platform independent access' 
category. Also Stream's 'normalized access' category. ByteArray methods 
use 'short' and 'long' for names. Stream uses 'SignedInt16' or 
'UnsignedInt32'. Once we agree on a naming scheme, we'd update all these 
to be consistent with it.

Still, I think it is nice for peope to be able to do `anInt16Array + 
anotherInt16Array` or `aFloat32Array + anotherFloat32Array` and get in 
each case an appropriate result.

>
> 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. But 'uintptr_t' access would be 32 bit in 32 bit images, and 64 bit 
in 64 bit images. 'int16', 'int32' and 'int64' would access 2, 4 and 8 
bytes at once on every platform. So they are different thing for me. 
Both make sense.

>
> On 5/26/19 13:49, Juan Vuletich via Cuis-dev wrote:
>>
>> Folks, these names are getting confusing. I think we'd name them 
>> better. What about ByteArray, SignedByteArray, Int16Array, 
>> SignedInt16Array, Int32Array, SignedInt32Array, Int64Array, 
>> SignedInt64Array, Float32Array,  Double64Array, SignedPoint16Array 
>> and SignedPoint32Array?


-- 
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