[
https://issues.apache.org/jira/browse/GEOMETRY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16523087#comment-16523087
]
Matt Juntunen commented on GEOMETRY-3:
--------------------------------------
I'm getting emails now! Yay!
I think we might have a miscommunication on the current parsing functionality
in the pull request. All of the 8 (soon to be 10) VALJOs only accept the string
format returned by the corresponding toString() method. This meets the simple
one-to-string Object <-> String mapping requirement you mentioned. The formats
are:
* Point1D: "(1.0)"
* Vector1D: "\{1.0}"
* Point2D: "(1.0, 2.0)"
* Vector2D: "\{1.0, 2.0}"
* Point3D: "(1.0, 2.0, 3.0)"
* Vector3D: "\{1.0, 2.0, 3.0}"
* S1Point: "(1.0)"
* S2Point: "(1.0, 2.0)"
* PolarCoordinates (not in this pull request): "(r=1.0, az=2.0)"
* SphericalCoordinates (not in this pull request): "(r=1.0, az=2.0, pl=3.0)"
So, the Vector3D.parse() method only accepts strings with the format "\{1,2,3}"
where there is a set of braces enclosing three comma-delimited floating-point
numbers. The string "(1,2,3)" will not work since it is enclosed with
parentheses and not braces. (I'm following the convention of using parenthese
for points and braces for vectors.) Similarly, PolarCoordinates.parse() only
accepts the format "(r=1, az=2)" where there is a set of of parentheses
enclosing two floating-point numbers where the string "r=" precedes the first
number and the string "az=" precedes the second. The string "(az=2, r=1)" does
not work. I chose to put the string prefixes in the PolarCoordinates and
SphericalCoordinates formats to 1) make it explicit what each number means and
2) differentiate them from the Point?D formats.
The formats for all of the different VALJO types are very similar and differ
only in the prefixes and suffixes used, the number of coordinate values, and a
few special string tokens (ex: "r=" and "az=" in PolarCoordinates). Rather than
duplicating the low-level string parsing code in each type, I pulled it out
into the o.a.c.g.core.util.AbstractCoordinateParser and
o.a.c.g.core.util.SimpleCoordinateFormat classes.
>From previous comments, it seems to me that the only decision that still needs
>to be made here is where to put the two low-level parser classes. I put them
>in core because they're used in commons-geometry-euclidean and
>commons-geometry-spherical, but I have no problem putting them somewhere else
>if needed. What do you think?
> Make Points and Vectors VALJOs
> ------------------------------
>
> Key: GEOMETRY-3
> URL: https://issues.apache.org/jira/browse/GEOMETRY-3
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Reporter: Matt Juntunen
> Assignee: Matt Juntunen
> Priority: Minor
>
> Ensure that all Point and Vector classes meet the requirements for being
> VALJOs as described here:
> [http://blog.joda.org/2014/03/valjos-value-java-objects.html]. Some of this
> work has already been done as part of GEOMETRY-2. The classes to update are:
> * o.a.c.geometry.euclidean.oned.Point1D/Vector1D
> * o.a.c.geometry.euclidean.twod.Point2D/Vector2D
> * o.a.c.geometry.euclidean.threed.Point3D/Vector3D
> * o.a.c.geometry.spherical.oned.S1Point
> * o.a.c.geometry.spherical.twod.S2Point
> Required changes include the following:
> * Create static factory methods for creating instances using the "of" naming
> convention.
> * Make constructors private
> * Add parse methods to return instances from "canonical" toString
> representation
> * Update all uses of the class to use the factory methods instead of the
> constructor
>
> Pull request: https://github.com/apache/commons-geometry/pull/4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
