Hello.
>
> >>> I started to work on the proposed new features, namely convex hull and
> >>> voronoi diagrams but am a bit stuck with the API design.
> >>>
> >>> The current type structure in the geometry package introduced a so
> >>> called Space with different implementation for 1D, 2D and 3D. To
> >>> represent a Vector in the respective space, a Vector<S extends Space>
> >>> interface exists, with implementing classes for each Space:
> >>>
> >>> * Vector1D
> >>> * Vector2D
> >>> * Vector3D
> >>>
> >>> Unfortunately, the Vector interface does not provide a generic access
> >>> method to each component, e.g. get(int) to get the ith component of the
> >>> vector. Each subclass has its own getX(), getY() ... method according to
> >>> the dimension of the Space. This makes it impossible to implement a
> >>> generic algorithm using the Space as type parameter.
> >>
> >> Yes, it would be nice to add a generic getter. In fact, we also thought
> >> about implementing the whole RealVector methods. This has to be thought
> >> again since now RealVector is an abstract class.
> >>
> >
> > We should be careful not to prevent future flexibility by assuming that a
> > "Vector" is a Cartesian vector.
> > I.e. we should not assume that a generic getter "get(int)" will return the
> > Cartesian coordinates. Maybe that an extended interface would do:
> > -----
> > public interface Cartesian<S> extends Vector<S extends Space> {
> > public double getCartesianCoordinate(int i);
> > }
> > -----
> >
>
> hmm, I am split on this. It sounds right but may also introduce an
> additional layer that is not necessary at all.
It's true that we could just add a method to the "Vector" interface:
-----
public double getCartesianCoordinate(int i);
-----
[But it should not be named "get(int i)" since that would be confusing if we
ever wanted to create a subclass, say of "Vector3D", to represent spherical
coordinates.]
> [...]
> > I'd be wary about creating a mirror of what is under "euclidean" (i.e.
> > "oned", "twod", etc.); e.g. this would better be avoided:
> >
> > euclidean/oned
> > /twod
> > /threed
> > hull/oned
> > /twod
> > /threed
> >
> > Ideally, common (non-dimension-specific) algorithms would go under "hull"
> > and dimension-specific implementations (if needed or useful) would go under
> > the corresponding sub-packages of "euclidean".
>
> this sound like a good plan, I did not intend to reproduce the
> oned/twod/threed package structure from the euclidean package.
>
> Otoh, distributing implementations over several packages could also be
> confusing for users (and for developers too). [...]
The idea was to group tools by dimension, like there is now e.g. "Vector3D"
and (tridimensional) "Rotation" in the same "threed" subpackage of
"geometry".
> [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
