← Back to team overview

kicad-developers team mailing list archive



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

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.



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