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

Matt Juntunen commented on GEOMETRY-23:
---------------------------------------

bq. Implementation-wise, yes, but the API is wrong, because a vector is not a 
set of Cartesian coordinates (the reverse is true).

No one is saying that a vector *is* a set of Cartesian coordinates. I would say 
you have a point if we were discussing the generic {{Vector}} interface but 
we're discussing concrete classes here. We've chosen (rightly so) to use 
Cartesian coordinates to represent Euclidean vectors in our *primary* vector 
implementation classes. We've also chosen the absolute simplest name for what 
these concrete classes represent, eg {{Vector2D}}, a Euclidean vector in two 
dimensions. Since we've chosen that {{Vector2D}} is represented by {{(x, y)}} 
Cartesian coordinates, then our VALJO "valueOf" method should just accept those 
arguments and set them directly. In other words, {{Vector2D.of(1, 2)}}, means 
"give me a {{Vector2D}} with values 1 and 2." No conversion of the inputs is 
required. For polar coordinates, a conversion *is* required, so we don't use a 
"valueOf" method. Instead, we use {{fromPolar}} to indicate that a conversion 
is taking place. (Here, I think the API does need to change since we currently 
have {{ofPolar}}). I don't see how any of this is mathematically inaccurate or 
misleading/confusing from an API perspective. Nothing in the API is preventing 
the creation of {{PolarVector}} or {{BarycentricVector2D}} classes and their 
use as vectors. 

As far as the name {{Vector2D}} goes, there are plenty of precedents for 
choosing a simple name to represent a specific implementation of something more 
generic. For example, {{java.lang.String}} is not named 
{{java.lang.UTF16String}} even though that would technically be more accurate.

Anyway, I just posted about this on the dev ML so hopefully we'll get some 
other input soon.


> Remove Euclidean Point Classes
> ------------------------------
>
>                 Key: GEOMETRY-23
>                 URL: https://issues.apache.org/jira/browse/GEOMETRY-23
>             Project: Apache Commons Geometry
>          Issue Type: Improvement
>            Reporter: Matt Juntunen
>            Priority: Major
>              Labels: pull-request-available
>
> Based on discussion of the current Point/Vector API in GEOMETRY-14 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 commons-math design but avoids the issue 
> raised in MATH-1284 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/commons-geometry/pull/15



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

Reply via email to