Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vectors: Default, missing Vector2 constants, documentation #718

Merged
merged 1 commit into from Apr 3, 2021

Conversation

Bromeon
Copy link
Member

@Bromeon Bromeon commented Apr 3, 2021

Completes a part of the recent Vector2/Vector3 refactoring:

  • impl Default (zero vector) for both
  • associated constants for Vector2
  • documentation of constants

Let me know if there's other obvious things that could fit.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! One tiny point about the docs of INF.

/// A vector with all components set to 1. Typically used for scaling.
pub const ONE: Vector2 = Vector2::new(1.0, 1.0);

/// A vector with all components set to infinity.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if the distinction is important to make, but I've heard positive infinity be called +Infinity for clarity elsewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can clarify that.

Maybe a general question, what's the use case of this INF constant? Some "default" intervals like [-Vector2.INF, Vector2.INF] which are interpreted component-wise?

And secondly, we do want to map every single constant that exists in Godot for completeness, independently of how useful it is, right? (also because it may not be easy to measure utility...)

Copy link

@ghost ghost Apr 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use case of INF... we do want to map every single constant that exists in Godot for completeness, independently of how useful it is, right? (also because it may not be easy to measure utility...)

I don't know, and yes I think you nailed the problem here. I'd err on the side of accepting constants of dubious usefulness because of this. There isn't a downside imo.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Thanks!

bors r+

@Bromeon
Copy link
Member Author

Bromeon commented Apr 3, 2021

Documented "+infinity", no changes otherwise.

Regarding the new Vector API, there's one other issue I'm currently aware of -- a compiler warning:

warning: associated function is never used: `glam`
  --> gdnative-core\src\core_types\quat.rs:27:8
   |
27 |     fn glam(self) -> glam::Quat {
   |        ^^^^
   |
   = note: `#[warn(dead_code)]` on by default

We could suppress it now, or work on the Quat API, or leave it active as a reminder that we should complete the API at some point 🙂

@ghost
Copy link

ghost commented Apr 3, 2021

We could suppress it now, or work on the Quat API, or leave it active as a reminder that we should complete the API at some point 🙂

Ideally we want 2, of course, but you don't have to work on it if you don't want to. 3 is a good idea, even though it might interfere with workflows where all warnings are denied (not the best idea imo, since that is simply opting out of Rust's stability). I think it can be left as is for now.

@bors
Copy link
Contributor

bors bot commented Apr 3, 2021

Build succeeded:

@bors bors bot merged commit 4c5184c into godot-rust:master Apr 3, 2021
@ghost ghost mentioned this pull request May 1, 2021
7 tasks
@Bromeon Bromeon deleted the feature/vector-const branch August 30, 2021 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant