<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 5/27/2019 4:56 AM, Luciano Notarfrancesco via Cuis-dev wrote:
<blockquote
cite="mid:CAL5GDypDa-uvNUsPr=id46ZUcb8jn7uB3e6p0xMLjavF8x51pg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="ltr">On Mon, May 27, 2019 at 5:27 AM Andres Valloud
via Cuis-dev <<a moz-do-not-send="true"
href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">VW has a useful abstraction for this,
the class UninterpretedBytes. <br>
While at first similar to a regular ByteArray,
UninterpretedBytes <br>
implements things like shortAt:, doubleAt:put: and so on.
Now you need <br>
just one class instead of n.<br>
<br>
</blockquote>
<div> </div>
<div>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...<br>
</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
If those selectors could be named after standard types of
fixed length <br>
too (like 'uintptr_t'), then great because e.g. nobody says
what the <br>
size of a C 'long' is.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
</body>
</html>