[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644363#comment-16644363
]
Matt Juntunen commented on GEOMETRY-14:
---------------------------------------
As far as the point/vector thing goes, I'm hesitant to change anything now
since a lot of work has gone into the current structure. You are right in that
there isn't much of a _need_ to have separate classes, although I still like it
the way it is. I think it makes algorithms very clear and the meaning of
variables very precise. If we go back to a single class that implements both
point and vector, then I feel like we'd be back where we were at the end of
MATH-1284 with the Cartesian?D classes being used everywhere. I'm not a fan of
that structure since I feel like it obfuscates the meaning of the code to have
a class name that's not either Point or Vector. So, do we want to be
mathematically pure or programmatically concise? Now that we've moved to a
VALJO system for these types and no one is calling {{new}} on anything, we may
actually have more options available in the design on this point. I'm not sure
yet. Currently, I think I just want to keep it the way it is and maybe ponder
if there are any better options.
{quote}However, do you see a real use-case where the composition of transforms
would need more than this method:
{quote}
Nope. The {{combine}} methods should do it.
{quote}Can the API of {{AffineTransform3D}} be discussed without including
rotations?
{quote}
No, I don't want to merge anything without that. I left it out for now so we
could discuss the less complicated parts of the API first. For the 3D case, I'm
planning on having {{Rotation}} be a separate class that implements
{{Transform}} from core but is not part of the {{AffineTransform}} hierarchy.
There will be methods that convert back and forth between them. I'm picturing
methods like this:
{code:java}
// AffineTransform3D
// apply a rotation to the current transform and return a new instance
public AffineTransform3D rotate(Rotation rot) {...}
// extract the rotation portion of the transform
public Rotation getRotation() {... }
// convert the given rotation to a matrix-based transform
public AffineTransform3D createRotation(Rotation rot) { ... }
{code}
I think I have a good idea of where to go on this issue now, so I'm going to
close my pull request and work on it some more. It might be a bit before I can
get another pull request in since I'm anticipating a fair amount of work and
I'm not going to have any time available for at least a week.
> 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)
