[Development] QList

[Edward Welbourne]

On 27 Mar 2017, at 10:52, Martin Smith <Martin.Smith at qt.io> wrote:
>> It was about whether QPolygon should inherit QVector, which means
>> that a polygon is a vector. That is kind of jolting because people
>> don't think of a polygon as being a vector. But back in the day,
>> calling a sequential collection of items a vector was also a jolt,
>> because at that time, a vector was a direction and a length to most
>> people.

Shawn Rutledge (27 March 2017 11:27)
> Well you may think of it that way geometrically, but usually need to
> do the calculations with vectors in component form.

Well, to a linear algebraist (at least this one) a vector is any damn
thing you know how to add to similar things and scale by some field of
scalings.  Which is entirely irrelevant here because we're not talking
about linear algebra.

The word just means "thing that carries"; indeed, medics use it to
talk about things that carry (for example) diseases.  Which is still
irrelevant because we're not talking about etymology, epidemiology or
Latin.

In early number-crunching software, there were vector quantities that
(entirely naturally) got represented as arrays of numbers; which has
lead to a tradition in the world of computer science of using "vector"
as a fancy word for an array (with some connotations about how you're
treating that array).  Which is the relevant meaning of the word because
we *are* talking about computer software.

>> So given the 20 year history of vector being a sequential collection
>> of items, it isn't really a problem for QPolygon to inherit QVector,
>> because everyone will come to think of a polygon as a vector just as
>> we came to think of a vector as a sequential collection of items.

Well, a polygon is a sequential collection of points (officially modulo
an equivalence relation that ignores cyclic permutations of the
sequence, which just change which vertex you chose to start at; ignoring
that equivalence, we have a polygon with one vertex marked, which is
a perfectly practical surrogate by which to represent the polygon in
software) which does mean it can *be represented* as any old sequential
collection of points, but does not in any way select *one particular*
choice of implementation as the one that a polygon "is".  If the use of
a particular implementation of "sequential collection" proves fruitful,
by all means use it; but if one proves problematic, perhaps try another.
It turns out that (apparently) one of the tool-chains we support behaves
badly around exporting a type based on a non-exported template.  So
let's not do that - oh, woops, we already did, so we have to deal with
that as gracefully as we can (and plan on how to unmake this mistake).

>> Still, if you have a QVector<frob> with 57 elements, you can think of
>> it as a point in 57-dimensional frobspace, if you like.  So our use
>> of vector is not completely out of sync with the mathematical sense,
>> even if adding and removing dimensions to our space all the time is
>> kindof absurd.

Indeed: back to being a linear algebraist, the space of sequential
collections of points in one space is itself a linear space, over the
same field, albeit of higher dimension; and indeed polygons in the
original space can be represented as points in this derived space,
albeit the equivalence mentioned above (that it's entirely practical for
software to ignore, usually) is going to do some fun things to it,
leaving you with a smooth manifold rather than a vector space - but we
digress.

	Eddy.