kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/21/2011 7:52 PM, Vladimir Uryvaev wrote:
> 
> As I see, there's no more (or very little) activity on this task.
> 
> I developed the approach on how to convert KiCAD to metric unit. This approach 
> is fully based on OOP.
> 
> There are several stages on converting:
> 
> 1. Preparation:
> 
> Create class of length:
> 
> class LENGTH {
>     int m_Units; // internal representstion
>     ...
> 
> There's would be no direct casts between any regular numeric types, and code 
> like:
> 
> LENGTH aLength = 50;
> 
> or
> 
> int value = aLength;
> 
> would cause an error. Any conversion then should be made explicit:
> 
> LENGTH aLength = 50 * mil;
> 
> int value = x / mil
> 
> 'mil' is predefined constant of length 1 mil which is then scaled or used as 
> reference, other constants, like 'millimeter' are follow. Actually they may be 
> static methods of LENGTH and actually invoked as LENGTH::mil();
> 
> Also classes for 2D point (say LENGTH_XY) and other convenient classes could 
> be written.
> 
> 2. Converting data storage:
> 
> Find all the vital classes where length data are stored. They would be classes 
> for graphic primitives, PINs etc.
> 
> Change type for the data to the brand new classes. Then find all access points 
> for such data and insert data conversion code to/from legacy types.
> 
> E.G.
> int m_Radius; - would become => LENGTH m_Radius;
> m_Radius = x => m_Radius = LENGTH::mil * x
> x = m_Radius => x = m_Radius / LENGTH::mil
> (mil is for example, would change it to the actual units involved)
> 
> 3. Convert data processing
> There would be iterative process on arithmetic, like
> 
> m_Radius / LENGTH::mil * 2 => m_Radius * 2 / LENGTH::mil
> 
> 4. Cleaning up
> We would end up with dummy coversion pairs, like
> 
> x = (y / LENGTH::mil) * LENGTH::mil;
> 
> So they need to be removed.
> 
> This approach when implemeted carefully would not break an application in any 
> stage, so there no need to make any fork or delay development in any other 
> manner. So I am ready to begin.
> 
> Let me know if I missed something, or if there's need to coordinate the work. 
> I would also like to know if someone is done something on this task so I would 
> coordinate with.

Vladimir,

I think your concept and logic are sound.  I like the idea that you have given
thought to incrementally replacing lengths and coordinates without breaking
anything rather than one huge commit that has the potential to break a lot of
things.  I just took a look at your initial commit and it seems reasonable.  I
have two minor issues.  The LENGTH_XY class name is a bit confusing.  An X, Y
coordinate pair does not imply length.  A better name for this class might be
COORDINATE_XY() or simply XY().  The other potential issue is the performance
penalty by using an object instead of a standard C type.  In EESchema this is
unlikely to be an issue since the number of drawable objects is relatively
small.  Performance in PCBNew might be a different issue.

Wayne

> 
> I saw Brian Bidulock started doing conversion but his branch seem to be 
> abandoned.
>