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

[Shaping]

+1

 

Word can be vague.  Even a byte can be 7-bits in some odd cases.  Counting bits is clearest and most reliable.  We all still agree on how big a bit is.

 

 

 

 

-----Original Message-----
From: Cuis-dev [mailto:cuis-dev-bounces at lists.cuis.st] On Behalf Of john pfersich via Cuis-dev
Sent: Monday, May 27, 2019 00:33
To: Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st>
Cc: john pfersich <jpfersich at gmail.com>
Subject: Re: [Cuis-dev] [Integrated] Should we rename these? Re: support for variable indexable subclasses of 8/16/32/64 bits

 

+1

 

/*—————————————————-*/

Sent from my iPhone

 <https://boincstats.com/signature/-1/user/51616339056/sig.png> https://boincstats.com/signature/-1/user/51616339056/sig.png

See  <https://objectnets.net> https://objectnets.net and  <https://objectnets.org> https://objectnets.org

 

> On May 26, 2019, at 22:27, Andres Valloud via Cuis-dev < <mailto:cuis-dev at lists.cuis.st> cuis-dev at lists.cuis.st> 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.

> 

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

> 

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

> -- 

> Cuis-dev mailing list

>  <mailto:Cuis-dev at lists.cuis.st> Cuis-dev at lists.cuis.st

>  <https://lists.cuis.st/mailman/listinfo/cuis-dev> https://lists.cuis.st/mailman/listinfo/cuis-dev

-- 

Cuis-dev mailing list

 <mailto:Cuis-dev at lists.cuis.st> Cuis-dev at lists.cuis.st

 <https://lists.cuis.st/mailman/listinfo/cuis-dev> https://lists.cuis.st/mailman/listinfo/cuis-dev

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