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

Matt Juntunen commented on GEOMETRY-92:
---------------------------------------

bq. But the argument is that what is good for Span is IMHO equally good for Ray:

If we want to standardize the convex subline implementations here, I would 
prefer to place {{Span}} in its own class than to put everything into {{Line}}. 
I much prefer the top-level class names of {{Ray}} and {{Segment}} to the 
qualified ones {{Line.Ray}} and {{Line.Segment}}. It will also be easier to 
maintain that way.

bq. Hence it seems natural to ask whether there is something to share, 
implementation-wise, so as to make that fact explicit. A HalfLine3D class?

They could. I considered that for a bit but did not end up doing it since they 
would only share implementations for the methods {{isFull()}}, {{isFinite()}}, 
{{isInfinite()}}, and {{getSize()}}.



> 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
>              Labels: beta1
>          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)

Reply via email to