Re: [Numbers] Inheritance and ValJO ? (Was: Where to define "quaternion"?)
> On Dec 12, 2018, at 5:48 PM, Stephen Colebourne wrote: > > I think this has already been worked out, but the main reason for no > inheritance is that is probably blocks future conversion to value types. > Composition instead of inheritance is usually the right solution. +1 to that. > > Stephen > > >> On Sun, 9 Dec 2018 at 10:21, Gilles wrote: >> >> Hello. >> >> After the discussion quote below, the conclusion was to go with >> inheritance: >> https://issues.apache.org/jira/browse/NUMBERS-80 >> >> However, it would make "Quaternion" fail the "ValJO" definition[1] >> that mandates that all constructors be private. >> >> Would a protected constructor really be an issue? >> [In the case of "Quaternion", the subclass constructor would only >> perform additional validation (cf. below for details).] >> >> >> Thanks, >> Gilles >> >> [1] https://blog.joda.org/2014/03/valjos-value-java-objects.html >> >>> On Mon, 03 Dec 2018 10:31:42 +0100, Gilles wrote: >>> Hi. >>> On Mon, 3 Dec 2018 03:56:02 +, Matt Juntunen wrote: I was just thinking from a practical standpoint. My current QuaternionRotation class is still in my working branch for GEOMETRY-14 and so isn't really accessible to anyone. If I can finish it up in its current state (hopefully very soon) and get it merged, then someone else will be able to work with it and blend the functionality with commons-numbers. >>> >>> Someone else? >>> Here are some notes on your questions from before: * Should "QuaternionRotation" inherit from "Quaternion"? That would work conceptually. The quaternions in the QuaternionRotation class are standard quaternions that meet two other criteria: 1) they are unit length, and 2) their scalar component is greater than or equal to zero (in order to standardize the angles involved). >>> >>> It seems indeed the perfect case for inheritance. >>> The one sticking point here is that I'm not sure how this fits with the VALJO concept. If we can get this sorted, then this very well may be the best option. >>> >>> What do you see as a potential issue? >>> * Should "Quaternion" be defined in [Geometry] (and removed from [Numbers])? Perhaps. I've certainly only used them to represent 3D rotations. Are there any other use cases from commons-numbers? >>> >>> Not within [Numbers], but that's the point of those very low-level >>> components/modules: they are common utilities used by higher-level >>> components/libraries/applications. >>> >>> Given that "QuaternionRotation" is a special case of "Quaternion", >>> it is logical to keep the latter at a lower-level, namely in >>> [Numebers], and make [Geometry] depend on it. >>> * Are some utilities defined in "QuaternionRotation" general such that they could be part of the [Numbers] "Quaternion" API. An example might be the transformation between quaternion and matrix (represented as a double[3][3])? The conversion to rotation matrix and slerp are the best candidates here. The other methods rely on core classes from commons-geometry, namely Vector3D. >>> >>> Is "slerp" applicable to a general "Quaternion", or does it assume >>> the additional requirements of "QuaternionRotation"? >>> [Same question applies to all utilities in order to decide where to >>> define them.] >>> One more note: I decided to make a separate package for 3D rotations in my working branch for GEOMETRY-14, so QuaternionRotation is now at >> https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/rotation/QuaternionRotation.java >> . >>> >>> Could you please update it so that it inherits from "Quaternion"? >>> >>> Thanks, >>> Gilles >>> -Matt From: Gilles Sent: Sunday, December 2, 2018 3:57 PM To: dev@commons.apache.org Subject: Re: [Numbers][Geometry] Where to define "quaternion" (Was: Making Quaternion a VALJO) > On Sun, 2 Dec 2018 19:20:03 +, Matt Juntunen wrote: > Unless anyone objects, I'm going to continue with what I'm working > on I certainly don't object on your working to improve the geometry code, but wherever that work overlaps with code being worked on elsewhere (in this case, the "Quaternion" class), then we'd rather have a discussion happening here first. > with QuaternionRotation and create a merge request. That way, we'll > at > least have a reference implementation and baseline functionality > for > commons-geometry that we can modify later based on what's decided > here. My questions below are a start; I'm waiting for answers. Code duplication is bad (TM). Regards
Re: [Numbers] Inheritance and ValJO ? (Was: Where to define "quaternion"?)
I think this has already been worked out, but the main reason for no inheritance is that is probably blocks future conversion to value types. Composition instead of inheritance is usually the right solution. Stephen On Sun, 9 Dec 2018 at 10:21, Gilles wrote: > Hello. > > After the discussion quote below, the conclusion was to go with > inheritance: >https://issues.apache.org/jira/browse/NUMBERS-80 > > However, it would make "Quaternion" fail the "ValJO" definition[1] > that mandates that all constructors be private. > > Would a protected constructor really be an issue? > [In the case of "Quaternion", the subclass constructor would only > perform additional validation (cf. below for details).] > > > Thanks, > Gilles > > [1] https://blog.joda.org/2014/03/valjos-value-java-objects.html > > On Mon, 03 Dec 2018 10:31:42 +0100, Gilles wrote: > > Hi. > > > > On Mon, 3 Dec 2018 03:56:02 +, Matt Juntunen wrote: > >> I was just thinking from a practical standpoint. My current > >> QuaternionRotation class is still in my working branch for > >> GEOMETRY-14 > >> and so isn't really accessible to anyone. If I can finish it up in > >> its > >> current state (hopefully very soon) and get it merged, then someone > >> else will be able to work with it and blend the functionality with > >> commons-numbers. > > > > Someone else? > > > >> > >> Here are some notes on your questions from before: > >> > >> * Should "QuaternionRotation" inherit from "Quaternion"? > >> > >> That would work conceptually. The quaternions in the > >> QuaternionRotation class are standard quaternions that meet two > >> other > >> criteria: 1) they are unit length, and 2) their scalar component is > >> greater than or equal to zero (in order to standardize the angles > >> involved). > > > > It seems indeed the perfect case for inheritance. > > > >> The one sticking point here is that I'm not sure how this > >> fits with the VALJO concept. If we can get this sorted, then this > >> very > >> well may be the best option. > > > > What do you see as a potential issue? > > > >> > >> * Should "Quaternion" be defined in [Geometry] (and removed from > >> [Numbers])? > >> > >> Perhaps. I've certainly only used them to represent 3D rotations. > >> Are > >> there any other use cases from commons-numbers? > > > > Not within [Numbers], but that's the point of those very low-level > > components/modules: they are common utilities used by higher-level > > components/libraries/applications. > > > > Given that "QuaternionRotation" is a special case of "Quaternion", > > it is logical to keep the latter at a lower-level, namely in > > [Numebers], and make [Geometry] depend on it. > > > >> > >> * Are some utilities defined in "QuaternionRotation" general > >> such that they could be part of the [Numbers] "Quaternion" API. > >> An example might be the transformation between quaternion and > >> matrix (represented as a double[3][3])? > >> > >> The conversion to rotation matrix and slerp are the best candidates > >> here. The other methods rely on core classes from commons-geometry, > >> namely Vector3D. > > > > Is "slerp" applicable to a general "Quaternion", or does it assume > > the additional requirements of "QuaternionRotation"? > > [Same question applies to all utilities in order to decide where to > > define them.] > > > >> > >> One more note: I decided to make a separate package for 3D rotations > >> in my working branch for GEOMETRY-14, so QuaternionRotation is now > >> at > >> > >> > https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/rotation/QuaternionRotation.java > . > > > > Could you please update it so that it inherits from "Quaternion"? > > > > Thanks, > > Gilles > > > >> > >> -Matt > >> > >> From: Gilles > >> Sent: Sunday, December 2, 2018 3:57 PM > >> To: dev@commons.apache.org > >> Subject: Re: [Numbers][Geometry] Where to define "quaternion" (Was: > >> Making Quaternion a VALJO) > >> > >> On Sun, 2 Dec 2018 19:20:03 +, Matt Juntunen wrote: > >>> Unless anyone objects, I'm going to continue with what I'm working > >>> on > >> > >> I certainly don't object on your working to improve the geometry > >> code, but wherever that work overlaps with code being worked on > >> elsewhere (in this case, the "Quaternion" class), then we'd > >> rather have a discussion happening here first. > >> > >>> with QuaternionRotation and create a merge request. That way, we'll > >>> at > >>> least have a reference implementation and baseline functionality > >>> for > >>> commons-geometry that we can modify later based on what's decided > >>> here. > >> > >> My questions below are a start; I'm waiting for answers. > >> Code duplication is bad (TM). > >> > >> Regards, > >> Gilles > >> > >>> > >>> -Matt > >>> > >>> From: Gilles > >>> Sent: Saturday, December 1, 2018 9:40 PM > >>> To: d
