[ https://issues.apache.org/jira/browse/GEOMETRY23?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=16674190#comment16674190
]
Matt Juntunen commented on GEOMETRY23:

It looks doubtful that we'll get any feedback from my post on the dev mailing list, so I guess
it's just up to us here. Bummer.
My main sticking point on this issue is that I want the names of our classes/methods to be
in line with other geometryrelated libraries. Every library I've seen uses some version of
a "vector" name (eg, {{Vector3f}}, {{Vector3}}, {{vec3}}) to represent points and vectors.
These classes also invariably use Cartesian coordinates. This includes GLSL, Three.js, G3D,
the Unity game engine, the JMonkey game engine, the Bullet physics engine, commonsmath, etc.
I'd like commonsgeometry to follow this industrystandard convention.
On a related note, I've thought about your points as they relate to the transform code I'm
working on now and I think that I could make some changes there in order to better reflect
the mathematical realities. So far I've changed {{AffineTransform?D}} to {{TransformMatrix?D}},
since matrices are only one way to implement affine transforms; and {{Rotation}} to {{QuaternionRotation}},
since I'm also planning on implementing rotations through Euler angles. These can be found
at https://github.com/darkma773r/commonsgeometry/tree/transforms. I only mention this to
say that I think you have a point with what you're saying; I just want to keep our vector/point
classes (the most basic building in our library) in line with industry standards.
What are your thoughts? As far as the coordinate conversion thing, I'm picturing that as a
separate ticket. I'll let you create that, since I like it the way it is:)
> Remove Euclidean Point Classes
> 
>
> Key: GEOMETRY23
> URL: https://issues.apache.org/jira/browse/GEOMETRY23
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Reporter: Matt Juntunen
> Priority: Major
> Labels: pullrequestavailable
>
> Based on discussion of the current Point/Vector API in GEOMETRY14 and research into
other geometric libraries, I think we should remove the Euclidean Point?D classes and make
Vector?D also implement Point. This will end up being similar to the previous commonsmath
design but avoids the issue raised in MATH1284 since the Point and Vector interfaces are
not related. They just happen to be implemented by the same class, which we're calling Vector?D
since a vector can be used to indicate a point (by adding it to the origin).
> In the course of trying this out this design, I ended up removing 7 classes and simplifying
several methods. I think that's a good indicator that this is a good design choice.
>
> Pull request: https://github.com/apache/commonsgeometry/pull/15

This message was sent by Atlassian JIRA
(v7.6.3#76005)
