Consider typed methods

[timshannon]

I was wondering if you would consider setting up some typed methods. It would make using the library a bit less verbose, and I don't believe it would be a performance issue.

vectormath.V3SetX(vector, 3.0)
x := vectormath.V3GetX(vector)

vector.SetX(3.0)
x := vector.X()

[spate]

Will do.

[james4k]

Along those lines, would you consider exporting the struct fields? Is there a reason to hide them behind accessors?

[spate]

I've been experimenting with changing the struct to an array. That way the elements would be directly accessible as array elements, or through the accessors by name.

It's a rather drastic change to the source, though, so I was hoping to play with it a bit first / try and work through most if not all of the implications. The part that I'd sort of got hung up on has to do with the matrices; this would make them an array of arrays. It might make more sense to make matrices a flat array, and then have the vectors they're composed of be slices into that array. That could have some performance implications for vector funcs, though, as well as potentially removing some of the static checking on the lengths of those types. So it might be preferable from that perspective for vectors to be a slice hidden inside of a struct? But that still doesn't address any potential performance impact of switching to a slice, so maybe it isn't worth it..?

Long story short.. maybe? :)

[timshannon]

I can't speak for others, but for me slices definitely work better. I wrote go bindings for the horde3d engine (http://code.google.com/p/gohorde/), and horde uses flat arrays ([16]float32) internally for matrices.

I can't speak to performance in go for structs vs arrays, but arrays would be naturally co-located in memory. Sounds like a good question for the mailing list.

[james4k]

Go has bounds checking on its arrays/slices, so it would unfortunately take a performance hit. Perhaps this isn't a huge issue, though, as you can disable bounds checking with -gcflags=-B for your production code.

[timshannon]

Good to know. Probably best to stick with structs then.

In which case, I'm all for exporting the struct fields as well. I believe the go tools have some nice stuff for doing that go fix -r or something.

[spate]

Hm, I guess it makes sense that they'd put bounds checking on the array accessors, but that's going to be annoying. If I stick with the current structs, that means a copy (or an unsafe cast) will be required in order to export the contents of a matrix to GL. Not sure how I feel about that; it's a pretty important use case imo.

[james4k]

For what it's worth, I'd say an unsafe cast is perfectly reasonable.