| Thread Previous • Date Previous • Date Next • Thread Next |
Hi Tom, On 23/06/2019 4:10 AM, Tomasz Wlostowski wrote:
On 22/06/2019 17:41, Reece R. Pollack wrote:While it is true that you can add two point coordinates and multiply by scalar 0.5 to get the midpoint, this is not true in the general case for arbitrary scalar multipliers. However, calculating the vector distance between two points, multiplying the vector by a scalar, then adding the resulting vector distance to the first point /does/ work in the general case. This is exactly the sort of bug that can be avoided by not allowing arbitrary operations on random vectors.I've never experienced a bug caused by mixing points/vectors together, at least in the math code. For passing coordinates/measurements from/to the GUI it might make sense to create custom types. Moreover, most if not all geometry libraries I've known used the same class for points and vectors. Single class for both is IMHO Occam's razor approach. As Seth already remarked, I would like to hear a solid argument for splitting point/vector classes, otherwise it looks like bikeshedding to me.
While it's cool that you have such a strong grasp of geometry operations and how they map to linear algebra, not everyone is at your level. Potential contributors to Kicad will have all sorts of backgrounds and be in the process of learning about geometry and or linear algebra. The math vector + geometric point VECTOR2 class technically works, but creates friction because to use it confidently one needs to read the class code and know a bit about how geometry operations are mapped to vector operations.
Splitting the classes into Vector, Point, and Delta (Spatial Vector), and restricting the behavior of each to match their math and geometry counterparts, will make it much easier for others to learn and come onboard.
Meanwhile, since you don't use spatial vectors erroneously, you won't see any new compiler errors, but people who are still learning about geometry will get useful feedback.
-Hauptmech
Tom PS1. I'm surprised no one yet noticed the VECTOR2<> class has public x/y members, which is an unforgivable violation of the tenets of classical OO design :-) PS2. There are some more serious OOD violations in KiCad codebase. Would anybody here volunteer to refactor the diamond in EDA_TEXT derivatives, DRAWSEGMENT/EDGE_MODULE classes or global variables in eeschema? _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
