I don't want to cruft table manipulations up with coordinate spaces.
Normal use of IntegerTables should require no understanding of
Position types and CSTs. Otherwise the abstraction has outgrown its
purpose.
Let's define a "Vector" as an integer indexed ImmuTable whose domain
is a contiguous set of integers, and whose least domain element is
always 0. WordVector would then be a kind of Vector. I propose that
Vectors are the kind of very light weight Tables that you are looking
for. Instead of the current n-ary overloaded "list" function, we
would have an (identically functioning) overloaded "vector" function.
Obviously, we can overload the definition of "fetch" & "get" of Vector
to take IntegerVar arguments.
I'm tempted to use the Smalltalk names Array, WordArray, ByteArray,
RunArray, etc rather than Vector. That way we won't confuse the CAD
developers :-) Comments?
*Normal* use of Vectors would not *require* anyone to be cognizant of
Positions or CoordinateSpaces. These only come up when we want to
deal with Vectors as a kind of Table, or when we want to deal with
Tables in more of their generality, specifically their generality of
being indexable by things other than integers. In this latter case,
being cognizant of Positions & CoordinateSpaces seem to me to be quite
appropriate.
This brings to mind the cost of ObjectAsPosition keys: It's hard to
explain. Oh well.
Do CoordinateSpace objects exist and know what kind of Positions are
appropriate for them?
The Vector idea makes sense for Array type things. Can you think of
an equivalent simplification for hash Tables? They are much harder to
explain. I can live with just the above simplification, though.
Go for it, Who.
dean