[
https://issues.apache.org/jira/browse/GEOMETRY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16523780#comment-16523780
]
Gilles commented on GEOMETRY-3:
-------------------------------
bq. we might have a miscommunication on the current parsing functionality
No, I see your point; but mine is that there is no added value in customizing
the format for this or that type of coordinates, {{Point}}, {{Vector}}, or
whatever object (ValJO), that is represented by a set of {{double}} values.
IMHO, all should follow the simple convention I mentioned before. The "meaning"
of the numbers is given in the code/Javadoc. Same for the implementation of
{{Complex}}, where there is no need to have a {{String}} representation such as
"(re=1, im=2)" since the doc makes it unambiguous what "(1, 2)" represents, if
it was output by {{Complex.toString()}}.
Of course, when "(1, 2)" can represent either Cartesian or polar coordinates,
or a complex number, it is error-prone if the functionality is used beyond its
intended purpose (usually limited to displaying a stack trace on the console,
where context is given by the call chain).
When people/application start to generate their own strings to represent code
objects, it is where flexibility, disambiguation and error detection are
needed; but that's the realm of data interchange, not ValJO. That is, if IIUC!
:)
What you called {{SimpleCoordinateFormat}} is not specific to the (space)
coordinate concept (it could have been called {{SimpleSetOfDoublesFormat}}).
That's one of the reasons I think it should not be part of the public API of
the "Geometry" component.
It's good to not duplicate utility code; thus, the function to parse coordinate
sets of different sizes should go in package named
{{o.a.c.g.core.util.internal}} (by convention, users cannot assume
backwards-compatibility for classes defined in such packages).
If I'm unclear, or I didn't convince you, I suggest that you raise the issue in
a post to the "dev" ML, where, hopefully, it will attract comments on best
practice for the VAlJO case.
> 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)
