search

go-gl / mathgl

A pure Go 3D math library.
BSD 3-Clause "New" or "Revised" License
554 stars 65 forks source link

Use new x/image/math/{f32,f64} packages internally. #35

Closed dmitshur closed 9 years ago

dmitshur commented 9 years ago

This is an internal code change, public API remains unchanged. No existing code should break.

The idea is to start using the new x/image/math/{f32,f64} packages that were finally added to Go (external) standard library. This is just a code organization change with no effect, but it will help us guide towards more standardization in the future. The underlying types are identical.

I've updated genprog/main.go to match, but I could not run it (aside from testing) because of #34.

Please review.

One observation I've made from making this PR is that everything works, but x/image/math/... is missing Mat2 type that mathgl has.

dmitshur commented 9 years ago

@Zaerei, any thoughts on this?

UserAB1236872 commented 9 years ago

Sorry, I've been swamped. Seems fine to me. We can slowly migrate to those functions too as they're added.

On Tue, Mar 3, 2015 at 11:06 PM, Dmitri Shuralyov notifications@github.com wrote:

@Jragonmiris https://github.com/Jragonmiris, any thoughts on this?

— Reply to this email directly or view it on GitHub https://github.com/go-gl/mathgl/pull/35#issuecomment-77106952.

dmitshur commented 9 years ago

We can slowly migrate to those functions too as they're added.

I agree with that. Merging.

pwaller commented 4 years ago

I discovered this in the context of #85 -- @dmitshur. I have a few "idle" questions. I'm not proposing any change at this stage but just want to increase my understanding by asking.

  1. What are the benefits of this change?
  2. Is it really worth it to introduce an external dependency just for the typedefs?
  3. Are there any effects of this other than changing the typedefs that I have missed?
  4. Is this possible to revert with no breaking changes?
UserAB1236872 commented 4 years ago

@pwaller IIRC we had a (minor) hand in the creation of the image extension library, whose types were partly based on mathgl itself in the first place so it would work with it. Somewhere in the original creation we specifically expressed interest in switching our definitions to the standard library ones once they were there just to keep things uniform.

UserAB1236872 commented 4 years ago

To expand, again IIRC there were originally plans to migrate some of the functionality into the standard library (or rather extension library) itself, which to my knowledge never materialized. Hence unifying the types, so we could just pass our types into those functions no fuss and just re-export our library to the new shiny standard ones for backwards compat.