feat: add axis normal vector constants to float and int modules #5

seancribbs commented 2026年02月23日 03:13:41 +01:00

More constants are good!

More constants are good!

renatillas commented 2026年02月23日 13:38:49 +01:00

Looks good!

Looks good!

NNB commented 2026年02月23日 15:33:49 +01:00

Good idea but the naming is confused with these functions, maybe the name should be x_positive, y_positive ext... would be better, and follow with that ?_negative would be useful too. As this would be similar to Godot's LEFT, RIGHT, UP, DOWN consts without enforcing which axis/sign to which direction.

Good idea but the naming is confused with [these functions](https://hexdocs.pm/vec/vec/vec2.html#x), maybe the name should be `x_positive`, `y_positive` ext... would be better, and follow with that `?_negative` would be useful too. As this would be similar to [Godot's `LEFT`, `RIGHT`, `UP`, `DOWN` consts](https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-constant-left) without enforcing which axis/sign to which direction.

renatillas commented 2026年02月23日 16:51:21 +01:00

I would personally get rid of the x and y functions as the vec type is not opaque and you can do vec.x and vec.y. I don’t see the verbosity in positive_x and positive _y

I would personally get rid of the x and y functions as the vec type is not opaque and you can do vec.x and vec.y. I don’t see the verbosity in positive_x and positive _y

seancribbs commented 2026年02月23日 17:24:55 +01:00

Happy to add neg_x, etc, and rename as needed. What's the consensus?

Happy to add `neg_x`, etc, and rename as needed. What's the consensus?

NNB commented 2026年02月23日 17:53:26 +01:00

Yep positive_* and negative_* is the way ;)

Yep `positive_*` and `negative_*` is the way ;)

NNB commented 2026年02月23日 18:31:25 +01:00

@renatillas wrote in #5 (comment):

I would personally get rid of the x and y functions as the vec type is not opaque and you can do vec.x and vec.y.

Yeah I know, I usually don't make that kind of functions, but the stdlib do have first and second functions for pair while user can just do pair.0, pair.1. So I think that: type that are generic and get use regular should have functions that extract element from it so it can be use in list.map(vec2.x) for example.

@renatillas wrote in https://codeberg.org/gwg/vec/pulls/5#issuecomment-10907495: > I would personally get rid of the x and y functions as the vec type is not opaque and you can do vec.x and vec.y. Yeah I know, I usually don't make that kind of functions, but the stdlib do have [`first`](https://hexdocs.pm/gleam_stdlib/gleam/pair.html#first) and [`second`](https://hexdocs.pm/gleam_stdlib/gleam/pair.html#second) functions for pair while user can just do `pair.0`, `pair.1`. So I think that: type that are generic and get use regular should have functions that extract element from it so it can be use in `list.map(vec2.x)` for example.

seancribbs commented 2026年04月05日 21:09:01 +02:00

@NNB I've updated my diff with the changes you suggested, let me know what you think!

@NNB I've updated my diff with the changes you suggested, let me know what you think!

NNB commented 2026年04月05日 21:12:45 +02:00

This seem good, Ima merge this now and retouch up some stuff and publish the change tomorrow, thank you!

This seem good, Ima merge this now and retouch up some stuff and publish the change tomorrow, thank you!