Re: [geometry] Points and Vectors Proposal
Hi,
I think one of the main issues here is that implementations of Point and Vector
need to have access to coordinate values in order to do work, but the generic
interfaces don't make that information accessible. We end up having to
constantly cast from inputs like Vector to Cartesian2D in the
implementation classes. This is true in the current code as well as in my
updated branch. This makes it difficult to allow for other coordinate systems.
So, what would you say to an interface structure like this:
interface Coordinates {
int getDimensions();
}
interface Spatial {
C getCoordinates();
}
interface Vector extends Spatial {
Vector add(Vector v);
// ... other methods
}
interface Point extends Spatial {
Vector subtract(Point p);
// ... other methods
}
class Euclidean2D implements Coordinates {
double getX();
double getY();
}
class Vector2D extends Euclidean2D implements Vector
Vector2D add(Vector v) {
Euclidean2D c = v.getCoordinates();
return new Vector2D(x + c.getX(), y + c.getY());
}
Euclidean2D getCoordinates() {
return this;
}
// ...
}
This is using your idea of having the coordinates be available through an
accessor method in order to avoid the need to cast types and make assumptions
about the coordinate system. Also, note that I'm not even using the Space
interface here. The only method that seems to be used in that class is
getDimensions() and that can easily be placed in the Coordinates interface.
-Matt
From: Gilles
Sent: Tuesday, April 24, 2018 7:55 AM
To: dev@commons.apache.org
Subject: Re: [geometry] Points and Vectors Proposal
Hi.
[Note: there is a problem with the quoted part in your
message.]
On Tue, 24 Apr 2018 01:31:43 +, Matt Juntunen wrote:
> Hi Gilles,
>
> The hierarchy would be wrong from a conceptual POV: A vector can be
> described by Cartesian coordinates, but it should be possible to
> introduce new coordinate systems (polar in 2D, spherical in 3D) ...
> This approach doesn't limit the coordinate system at all. We can
> still make implementations of Point and
> Vector based on other coordinate systems. I think it'll
> actually be easier in this structure, since the details of the system
> are explicitly defined in a single base class. For example, to create
> polar vectors and points, we would create a PolarCoordinate2D base
> class and PolarPoint2D and PolarVector2D subclasses.
What you propose (in the branch) is:
public class Point3D extends Cartesian3D
Then if we'd implement spherical coordinates, we'd have (similarly):
public class Point3D extends Spherical3D
Obviously, that will not work; so I may be missing what you
are trying to achieve...
> ...algorithms that use vectors would/should still work (transparently
> doing the appropriate conversions if necessary).
> This is a general issue with the current code, separate from the
> changes I'm proposing here. I'm not introducing a new issue.
What is the general issue? That the code assumes Cartesian
coordinates?
My understanding is that your proposal exposes an "implementation
detail" (a set choice of the coordinate system).
> I understand (and agree with) the performance goal, but let's
> be careful to not define an API that does not correspond to
> the underlying concepts.
> Agreed. One vote in favor of having these utility methods is that I
> used some of them while transitioning the other geometry classes for
> my proof-of-concept. For example,
> o.a.c.geometry.euclidean.threed.Plane uses the
> Vector3D.dotProduct(Cartesian3D, Cartesian3D) method to compute the
> origin offset directly from the origin point and plane normal.
I think that two issues are compounded here; one is the static
"utility" functions (whether they are more performant then
"pure" OO methods should be demonstrated, with benchmarks),
the other is the OO hierarchy, which should make sense from a
subject domain (i.e. geometry) POV. Here I was again referring
to the fact that e.g. a vector in Euclidean 3D-space is equally
well represented by
(x, y, z)
or
(r, theta, phi)
or
(r, theta, z)
or
...
Perhaps a "Cartesian3D" instance should be returned by an
accessor, rather than be the parent (?).
> What will happen when we introduce
>Spherical3D(r, theta, phi)
> alongside
>Cartesian3D(x, y, z)
> ?
> They should be able to get along just fine. They would each have
> subclasses that perform point and vector operations using their
> respective coordinate systems. The only issue would be trying to mix
> them, which as I mentioned above, is an existing issue with the
> current code base. However, I think having the coordinate systems
> encapsulated in base classes is a good first step in solving this.
[See above.]
> If "Cartesian3D" _implements_ "Point3D" and "Vector3D", it
> would still work (i.e. refactor so that "Point3D" becomes
> an interface and does not assume that the coordinates are
> Cart
Re: [compress] High Level API for Archives
Am 26.04.2018 um 17:37 schrieb Matt Sicker: > If it helps in design, the most promising approach I found was to integrate > with the java.nio.file API. However, that turns into a sort of hybrid > library between VFS and Compress. However, they are rather strongly related > (if the two libraries were modular, then it wouldn't be such a problem to > combine them). > > On 26 April 2018 at 10:04, Stefan Bodewig wrote: > >> On 2018-04-24, sebb wrote: >> >>> On 23 April 2018 at 20:48, Torsten Curdt wrote: TBH I am not such super big fan of adding and maintaining a high level API at this stage. You will never find the right abstraction that everyone is happy with. If you would - well, then that should be the real API afterall. >> Honestly - I would just add example code for now. Maybe that can turn into a helper class in the long run. But for now we would not introduce something we may no longer break. >> >>> I like the idea of introducing it as example code. >>> That makes it obvious that it will change. >> >> As the only people who spoke up prefer to not provide the API as an >> officially supported one, I'm fine with moving the stuff to an examples >> package, add a warning and add unit tests so we now it keeps on working. >> >> Unless anybody yells and says "no we really need this high level API", >> that is. >> >> I'd still like to spend some time and gather feedback on a nicer API >> than many overloads - is fluent the way to go? Recently I had a closer look at streaming libraries like Akka Streams. So I had the idea to model the problem in a similar way: An archive or deflate operation could be modeled by a flow from a source via some filtering or modifying stages to a sink. The source and the sink could both either refer to a directory or an archive file. In order to create a new archive, the source would point to a directory and the sink would represent the archive file to be created. To extract an archive file, it would be the other way around. When both the source and the sink point to an archive file, you have an update operation. So the basic concepts can be combined in a natural way. There could be stages that filter for files or archive entries to select the content of an archive file to be created or the files to be extracted. Maybe it makes also sense to map on entries to manipulate them somehow (rename?). The API could be extensible by allowing clients to create their own implementations of sources, sinks, and flow stages. Just some high-level thoughts without having thought that through. Oliver >> >>> If not, maybe put the code in an experimental package. >> >> The changeset package is in this state and has been like this for years >> now, I doubt we'd ever get anything out of the experimental phase :-) >> >> Stefan >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] High Level API for Archives
If it helps in design, the most promising approach I found was to integrate with the java.nio.file API. However, that turns into a sort of hybrid library between VFS and Compress. However, they are rather strongly related (if the two libraries were modular, then it wouldn't be such a problem to combine them). On 26 April 2018 at 10:04, Stefan Bodewig wrote: > On 2018-04-24, sebb wrote: > > > On 23 April 2018 at 20:48, Torsten Curdt wrote: > >> TBH I am not such super big fan of adding and maintaining a high level > >> API at this stage. > >> You will never find the right abstraction that everyone is happy with. > >> If you would - well, then that should be the real API afterall. > > >> Honestly - I would just add example code for now. Maybe that can turn > >> into a helper class in the long run. > >> But for now we would not introduce something we may no longer break. > > > I like the idea of introducing it as example code. > > That makes it obvious that it will change. > > As the only people who spoke up prefer to not provide the API as an > officially supported one, I'm fine with moving the stuff to an examples > package, add a warning and add unit tests so we now it keeps on working. > > Unless anybody yells and says "no we really need this high level API", > that is. > > I'd still like to spend some time and gather feedback on a nicer API > than many overloads - is fluent the way to go? > > > If not, maybe put the code in an experimental package. > > The changeset package is in this state and has been like this for years > now, I doubt we'd ever get anything out of the experimental phase :-) > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [compress] High Level API for Archives
On 2018-04-24, sebb wrote: > On 23 April 2018 at 20:48, Torsten Curdt wrote: >> TBH I am not such super big fan of adding and maintaining a high level >> API at this stage. >> You will never find the right abstraction that everyone is happy with. >> If you would - well, then that should be the real API afterall. >> Honestly - I would just add example code for now. Maybe that can turn >> into a helper class in the long run. >> But for now we would not introduce something we may no longer break. > I like the idea of introducing it as example code. > That makes it obvious that it will change. As the only people who spoke up prefer to not provide the API as an officially supported one, I'm fine with moving the stuff to an examples package, add a warning and add unit tests so we now it keeps on working. Unless anybody yells and says "no we really need this high level API", that is. I'd still like to spend some time and gather feedback on a nicer API than many overloads - is fluent the way to go? > If not, maybe put the code in an experimental package. The changeset package is in this state and has been like this for years now, I doubt we'd ever get anything out of the experimental phase :-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Need Help With PAX Exam Tests
On Wed, 2018-04-25 at 20:32 +0200, Stefan Bodewig wrote: > On 2018-04-25, Robert Munteanu wrote: > > > It is definitely possible to use a single project with Pax-Exam. > > Take a > > look for instance at > > https://github.com/cschneider/osgi-testing-example > > This is exactly what I needed, many thanks! > > I've committed a mostly empty unit test that fails if I remove a > colon > from the import-package configuration - exactly the problem that > caused > COMPRESS-442. Glad to hear that. RObert - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
