Vector2d: What is the recommended 1.x approach to accessing the removed helper methods

[IronReignRobotics]

How should teams moving from .5 to 1.x handle the helper methods from Vector2d that the previous version had like angleBetween(), distTo(), projectOnto() and rotated()

Thanks

[rbrott]

I deliberately pared down the API with the idea that it will be easier to add functionality to the API than remove functionality from it. I'm happy to consider methods on a case-by-case basis. I just don't want to add blanket backwards support.

Let's look at the few you mentioned as a start.

• angleBetween(): This doesn't exist in the new API. I think it's better implemented as a free function anyway.
• distTo(): Also doesn't exist now. Also should be a free function.
• projectOnto(): Doesn't exist now. Hard for me to see this getting much use.
• rotated(): Moved to Rotation2d in the form of times(). It's common for other robotics/geometry APIs to represent rotated() as the application of a rotation to a vector where "application" is generally expressed by times. Might be worth emphasizing that in the API.

And even if I decide not to add something back, I'm happy to show how I would implement it in terms of the new geometry primitives.

[IronReignRobotics]

angleBetween() or getBearingTo() and distTo() are the ones that are most critical to us. We have implemented them separately, but last year we used the versions from RR and we just wanted to know if those are coming back. It's interesting that the variant from apache commons Euclidean geometry Vector2D class also has similar functions built in, so I just curious why you're thinking of them as free function, should they come back. just wanting to learn.

[rbrott]

angleBetween() or getBearingTo() and distTo() are the ones that are most critical to us. We have implemented them separately,

Oh nice.

but last year we used the versions from RR and we just wanted to know if those are coming back.

My current inclination is to exclude them, though I'm open to being convinced otherwise.

It's interesting that the variant from apache commons Euclidean geometry Vector2D class also has similar functions built in, so I just curious why you're thinking of them as free function, should they come back. just wanting to learn.

I brought up the free function angle only because free functions can be added by a user without library support and used with the same syntax as if they were in the library to begin with. That isn't the case in Java with normal methods, and that fact IMO weighs more in favor of including additional utility methods in the library.

[IronReignRobotics]

Can't say we have a convincing argument, but we'd be happy for having them included in the library. It makes sense, for instance, when dynamically doing a just-in-time build of an action sequence that wants a tangent to a destination from a variable starting point.