[
https://issues.apache.org/jira/browse/GEOMETRY-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086922#comment-17086922
]
Matt Juntunen commented on GEOMETRY-92:
---------------------------------------
{quote}...couldn't they all be a nested class of {{Line3D?}}
{quote}
I'd rather keep the classes besides {{Span}} as non-nested classes since 1)
they will be used quite frequently, 2) they represent top-level concepts, 3)
they contain their own static factory methods. {{Span}} I consider a little bit
different since it represents the exact same points as the line. This,
{code:java}
Ray3D ray = Ray3D.fromPointAndDirection(pt, dir, precision);
{code}
looks cleaner (and easier to read) to me than
{code:java}
Line3D.Ray ray = Line3D.rayFromPointAndDirection(pt, dir, precision);
{code}
bq. choose "OppositeRay", in place of "TerminatedLine".
As defined in the wikipedia page "opposite ray" doesn't quite match what we're
trying to represent here. As defined there, "opposite ray" means a ray with the
same starting point as another but with the opposite line direction. Here,
we're trying to represent a portion of a line that only has an end point and no
start point, which is not a ray at all.
I could picture using the name {{ReverseRay}} here, however. That would avoid
the issue mentioned above and give us this nice correlation with the
{{reverse}} method:
{code:java}
Ray ray = Ray.fromPointAndDirection(pt, dir, precision);
ReverseRay reverseRay = ray.reverse();
Ray otherRay = reverseRay.reverse();
{code}
> Segment is not mathematically correct
> -------------------------------------
>
> Key: GEOMETRY-92
> URL: https://issues.apache.org/jira/browse/GEOMETRY-92
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Reporter: Matt Juntunen
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{Segment}} class is not mathematically correct because line segments are
> defined as having distinct start and end points, whereas the start and end
> points in {{Segment}} are optional. In other words, an instance of
> {{Segment}} can represent an entire line, a ray, or a segment. I propose
> renaming the existing {{Segment}} class to {{ConvexSubLine}} and creating
> subclasses to represent the distinct types of sublines.
> * {{ConvexSubLine}} - Abstract convex subline class. The factory methods
> (such as fromPoints()), would examine the inputs and return one of the
> specific subclasses below. Each subclass would also contain its own factory
> methods that apply input validation (eg, no null points when creating a
> {{Segment}}). This would also allow each subclass to optimize some
> computations based on the known characteristics of the represented entity.
> ** {{FullLine}} - no start or end points
> ** {{Segment}} - contains non-null start point and end point
> ** {{Ray}} - contains non-null start point and null end point
> ** {{ReverseRay}} - contains non-null end point and null start point (not
> sure if there is a more mathematical term for this)
> These changes would also apply to the 3D classes:
> * {{ConvexSubLine3D}}
> ** {{FullLine3D}}
> ** {{Segment3D}}
> ** {{Ray3D}}
> ** {{ReverseRay3D}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
