On Fri, May 1, 2009 at 9:56 AM, Casey Duncan <ca...@pandora.com> 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. > > There's no good way to get dict-key-ability from a mutable vector. Using identity (like what surfaces does) would be bad, cause then two vectors that are equal wouldn't be the same key, and people wouldn't "get" that. Using a hash of the value has the problems of being prone to errors - it's just too easy to write code that iterates over the keys and accidentally changes the value of one, magically messing up your dict
