On 11/22/2011 08:12 AM, Brian F. G. Bidulock wrote: > Lorenzo, > > Well, this is a good example for you. Go look at what has to be > changed to change the trig functions to use, errr, libm! They > are called from all over hades' half-acre, always from outside > the object, always directly accessing members of the objects, > some places applying one round-off; some places, another; some > places making one assumption about round-off; another place, > another assumption; always outside the object. > > With a proper OO design, these trig functions would have been > hidden inside the class implementation instead of being strewn > everywhere. First impression, start with changing every mPoS > .x, .y direct access to a function on the object (no, not setX(), > getX(), nonsense, but move(d,a)). To see what it takes to do > that, just try making x and y and mPos private and give a go at > compiling. > > To do the least little thing, you have to get rid of the legacy > first. It is obvious from the code. So, my question, under > the current "managmement", why has this not happenned? For so > many years. My only conclusion is that the current "management" > is incapable of doing it for one reason or another. > > --brian
One of the best ways to get started actually contributing to KiCad is to offer byte sized patches which concentrate on one or two public member fields, and provides accessors for these, making the fields protected or private. I cannot tell you how many of these kinds of patches that Wayne and I have made. I did scores of them in 2008. Wayne has done more than that in the last two years. This procedure, if continued by enough man-hours, would transition KiCad more in the direction of an object oriented design. We remember that KiCad was originally C code not C++. So it has been in evolution for the last several years, all the while churning out boards that we all benefit from. Current "management" is incapable of doing this because current management is not paid enough to work on this project full time. To help with this evolution, the door is open to more volunteers. The product of the work should be reasonably sized patches, addressing one or two fields at a time. Even doing this, these are sometimes thousand line patches. No disagreement on the need. Just in attitude, and willingness to contribute in a way that is appropriate. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
