[jira] [Comment Edited] (GEOMETRY-14) AffineTransform?D Classes

["Matt Juntunen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640846#comment-16640846 ] 

Matt Juntunen edited comment on GEOMETRY-14 at 10/6/18 7:15 PM:
----------------------------------------------------------------

{quote}Yes, but {{apply(vec)}} is as clear and more concise, and now favored by the JDK.
{quote}
That makes sense. I think the naming of these methods is going to be critical to the ease of use of the API. How about this: the transform classes follow the JDK convention and have {{apply}} methods, eg {{transform.apply(vec)}} and {{transform.apply(pt)}}. We define _apply_ here to mean "take the calling transform and apply it to the given argument." For combining/chaining transforms, we use a _transform_ method, which we define as meaning "take the calling object and transform it with the argument." We would then have {{A.transform(B)}} mean "transform A with B", which would give us the correct order of operations, eg {{A.transform(B).transform(C)}} would logically perform A, then B, then C. We could also use this same definition of _transform_ in the vector/point classes. For example, {{vec.transform(t)}} means "transform vec with t."

 
{quote}Usual question: Why adding to the API?
{quote}
I want transforms to be able to be applied inline with other vector/point methods. For example, {{p1.vectorTo(p2).transform(t).normalize()}} instead of {{t.apply(p1.vectorTo(p2)).normalize()}}, which is more difficult to read.
{quote}Does that mean that the class is mutable?
{quote}
It is immutable from outside of the class. All of the methods like {{translate}} return new instances. I do not have the private fields set as final so that I can do things like copying the results of internal computations back into an existing instance.

 


was (Author: mattjuntunen):
{quote}Yes, but {{apply(vec)}} is as clear and more concise, and now favored by the JDK.
{quote}
That makes sense. I think the naming of these methods is going to be critical to the ease of use of the API. How about this: the transform classes follow the JDK convention and have {{apply}} methods, eg {{transform.apply(vec)}} and {{transform.apply(pt)}}. We define _apply_ here to mean "take the calling transform and apply it to the given argument." For combining/chaining transforms, we use a _transform_ method, which we define as meaning "take the calling object and transform it with the argument." We would then have {{A.transform(B)}} mean "transform A with B", which would give us the correct order of operations, eg {{A.transform(B).transform(C)}} would logically perform A, then B, then C. We could also use this same definition of _transform_ in the vector/point classes. For example, {{vec.transform(t)}} means "transform vec with t."

 
{quote}Usual question: Why adding to the API?
{quote}
I want transforms to be able to be applied inline with other vector/point methods. For example, {{p1.vectorTo(p2).transform(t).normalize()}} instead of {{t.transform(p1.vectorTo(p2)).normalize()}}, which is more difficult to read.
{quote}Does that mean that the class is mutable?
{quote}
It is immutable from outside of the class. All of the methods like {{translate}} return new instances. I do not have the private fields set as final so that I can do things like copying the results of internal computations back into an existing instance.

 

> 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)