[
https://issues.apache.org/jira/browse/GEOMETRY-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090577#comment-17090577
]
Gilles Sadowski commented on GEOMETRY-92:
-----------------------------------------
{quote}Are you suggesting that all classes have a suffix indicating their
dimension.
{quote}
No; I can guess that it would bring its own set of confusing interpretations
like "Is it the dimension of the space or of the embedded object?"...
But, as told previously, I'd think that nested classes could bring more clarity
by grouping classes that share common usage; e.g. something along
{code:java}
public final class Object2D {
public static class Line extends ... { // To replace "SubLine" (?).
// ...
}
public static class Segment extends ... {
// ...
}
public static class Circle extends ...
implements ConvexShape {
// ...
}
public interface ConvexShape {
// ...
}
// etc.
}
{code}
and
{code:java}
public final class Object3D {
public static class Line extends ... {
// ...
}
public static class Segment extends ... {
// ...
}
public static class Plane extends ... { // To replace "SubPlane" (?).
// ...
}
public static class Sphere implements ConvexShape {
// ...
}
public interface ConvexShape {
// ...
}
// etc.
}
{code}
That way (I imagine), we can reuse a common name like "line" that must have
different implementations according to the practical context: just "line" from
a user's POV (a {{Span}} currently), and the necessary (from a developer's POV)
distinction with a {{Line3D}}.
{quote}I'm confused about what changes you're proposing exactly.
{quote}
It's not clear for myself either, sorry. :-}
To take the currently most striking example: As already stated, the difference
(from a programming POV) between
{code:java}
Line3D.Span
{code}
and
{code:java}
Ray3D
{code}
hinders "self-documentation".
Going to just
{code:java}
Span3D
{code}
does not help (IMO) because "span" is not a standard term; users would surely
expect this functionality to be called {{Line}}. When first approaching this
library, it will obviously be easier for someone to build a geometric model
when all the tools (for that level of functionality) are grouped in a class
{{Object3D}} as evoked above.
We may want something more descriptive than "Object", or perhaps just {{O3D}}
is good enough as a namespace, for a newbie will only need one pass at the
documentation in order to remember that basic usage can start with classes
defined there.
I hope that the discussion has become a little clearer now... :)
> 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)
