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

[Justin Davis]

Hi,

I'm new here and I just switched to Cuis for playing with cryptology over the
weekend, after doing the same in Pharo. I'm chiming in because I was recently
looking through all of these classes and selectors you are talking about.  BTW,
*all* of the various naming conventions mentioned already exist in Pharo for
classes and accessors (ugh)!

On Monday, May 27, 2019 9:01 AM, Juan Vuletich via Cuis-dev <cuis-dev at lists.cuis.st> wrote:

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

I like these numbered names because they are not ambiguous. These remind me of
the Zig language, which is a great example of minimalism and clarity:
https://ziglang.org/documentation/master/#Primitive-Types

As already discussed the C naming is pretty terrible and ambiguous, even within
C itself! Many C libraries that care about this ambiguity use elaborate
preprocessing and only declare variables with macros (i.e. Win32 with DWORD,
QWORD).

I'd like to point out that "Word", "Double Word", "Quad Word" are also
ambiguous. A "Word" is often specific to a processor or microcontroller. A
32-bit ARM processor uses "word" to describe 32-bits and my 64-bit Intel
processor uses "word" to describe 16-bits! I'm guessing x86 architectures have
backwards compatibility for ~20 years and so it would be confusing to change the
meaning of the word "Word" every time they upgrade.  In other words, their word
for "word" is backwards compatible. :-)

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