Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Consider typed methods #1

Open
timshannon opened this Issue Oct 3, 2012 · 8 comments

Comments

Projects
None yet
3 participants

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()

@ghost ghost assigned spate Oct 3, 2012

Owner

spate commented Oct 3, 2012

Will do.

james4k commented Oct 3, 2012

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

Owner

spate commented Oct 3, 2012

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? :)

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 commented Oct 3, 2012

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.

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.

Owner

spate commented Oct 3, 2012

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 commented Oct 3, 2012

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

@spate spate added a commit that referenced this issue Oct 3, 2012

@spate spate Switch some funcs to be type methods; misc fixes
This is meant to help address #1. All trivially converted getters and setters
are now type methods, as are a number of functions that returned a single
value.

Also fixed: Sum functions and the Matrix3 Determinant function.
34c452b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment