[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641524#comment-16641524
]
Gilles commented on GEOMETRY-14:
--------------------------------
About {{Point}} and {{Vector}}, the question is simply to have (programming)
use-cases for both.
{quote}the difference is mathematical
{quote}
I like when the design can be close to the mathematical concepts. But you
argued that having
{code:java}
public class Vector3D extends Cartesian3D implements
MultiDimensionalEuclideanVector<Point3D, Vector3D>
{code}
and
{code:java}
public final class Point3D extends Cartesian3D implements
EuclideanPoint<Point3D, Vector3D>
{code}
was going to be more effective from a usage POV even though the class hierarchy
does not agree with the mathematics (a point exists independently of the
coordinate system).
So my (design) question is of the same order: If programming is allowed to be
a step away from mathematics, maybe (?) that a "point" class is not strictly
necessary (here).
As a basic user of a very small fraction of that code, I don't know (yet).
That's why I'm suggesting that, if possible, some real-use cases should be
presented for the concepts (a.o. _both_ "point" and "vector") that are
represented in the API.
If now is not a good time, then I can wait; but this is "for the record" of
trying to avoid issues as they seem to appear (at least to me). ;)
About affine transforms: I'm convinced that {{java.util.function}} is not going
to help then.
However, do you see a real use-case where the composition of transforms would
need more than this method:
{code:java}
public AffineTransform3D combine(AffineTransform3D transform) { /* ... */ }
public static AffineTransform3D combine(AffineTransform3D ... transforms) { /*
... */ }
{code}
together with the varargs static method shown above (as syntactic sugar)?
Note: I couldn't figure out the 3-arguments {{multiply}} method (in the PR).
Can the API of {{AffineTransform3D}} be discussed without including rotations?
Shall we just have
{code:java}
public Rotation extends AffineTransform3D { /* ... */ }
{code}
?
> AffineTransform?D Classes
> -------------------------
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
> Reporter: Matt Juntunen
> Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
