On Fri, May 1, 2009 at 9:56 AM, Casey Duncan
<casey@xxxxxxxxxxx> wrote:
I think that less memory management overhead and batch operations are strong arguments for mutable vectors.
The less memory management is a performance vs. correctness thing, and having used both extensively, and flip-flopped between the two multiple
times on what I regularly use, I find that I end up not using the
in-placeness of operations on mutable vectors very much anyways,
because they keep resulting in subtle and annoying bugs. Also, I find that the in-place stuff makes much harder to read code vs. having and using lots of canned functions for all kinds of common useful ops (i.e. doing a change of basis on a vector for instance). My point being, that in my experience, I'm not actually getting less memory management in practice from mutable vectors, cause in the end I'm making copies lots and using higher level functions as opposed to twiddling vectors manually.
Re: Batch operations, seem to me to be something where you'd really want to allocate the block of vectors all at once anyways, so they already should be a different beast than a single vector.
The predicability of immutable vectors is nice, but IMO the convenience and flexibility of mutable vectors, along with the consistency with existing type like Rect makes them win.
I agree the convenience and flexibility can be useful (the only case this matters to me in practice, btw, is wanting to change just one element of the vector, which is rare, but annoying when you can't do it)
I think consistency with the Rect type is a non-argument for mutability or not. Practical should win over the notion that all pygame classes should behave the same. If two things are different in use and results, their behavior should be adapted to accommodate those differences - in fact having consistent behavior can drive inconsistency in use.
In my experience, I've never wanted to take the rect property of something, do some operations on it and introduce a bug that way, and I've never wanted to use a rect as a key to a dict. However I've written some very confusing bugs taking a vector property of something and changing it accidentally, and I've been disappointed I couldn't use a vector as a key to a dict.
I would argue that it should be possible to treat vectors as immutable if you preferred that, which I think is covered by the features proposed so far.