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

Matt Juntunen commented on GEOMETRY-29:
---------------------------------------

{quote}hmm, what do you picture here ? .... double comparison ..., 
precisionContext
{quote}
I'm picturing following the same approach as the other refactored hyperplane 
classes, especially 
[o.a.c.g.euclidean.twod.Line|https://github.com/apache/commons-geometry/blob/master/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/Line.java#L338].
 Basically, the standard {{equals}} and {{hashCode}} methods perform exact 
comparisons in all cases, which goes for other objects in the library as well. 
Fuzzy comparisons are left for other methods.

bq. This one, does not make sense to me:

I'm not sure what you mean? Where did this code come from?





> Plane API cleanup
> -----------------
>
>                 Key: GEOMETRY-29
>                 URL: https://issues.apache.org/jira/browse/GEOMETRY-29
>             Project: Apache Commons Geometry
>          Issue Type: Improvement
>            Reporter: Matt Juntunen
>            Priority: Major
>
> The following changes should be made to the 
> {{o.a.c.g.euclidean.threed.Plane}} class:
>  * make the class immutable
>  * use well-named factory methods instead of constructor overloads
>  * provide a factory method to create a plane with user-supplied {{u}} and 
> {{v}} axes. The current implementation allows the normal to be provided but 
> chooses its own planar axes (see {{setFrame}}).
>  * add {{equals}}, {{hashCode}}, and {{toString}} methods.



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

Reply via email to