kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I guess I should comment on this seeing that I am the project leader.  I
am fine with refactoring as long as it's an improvement over existing
code.  In this case, I would say that some refactoring is in order
although I would proceed cautiously with the code in question.  OOP does
not necessary translate to more maintainable and/or understandable code.
 Please don't confuse programming paradigms for religion.  I have been
at this for 30 years and have heard the promises (sales pitches?) of how
every new programming paradigm was going to save us from ourselves.  I'm
still waiting ;)

On 6/23/19 11:03 AM, Simon Richter wrote:
> Hi,
> 
> On Fri, Jun 21, 2019 at 10:54:04PM -0400, Reece R. Pollack wrote:
> 
>> Just for discussion, let's assume the replacement for wxPoint is
>> named KiPoint. The result of subtracting two KiPoint objects would
>> be another object called KiDelta. Adding two KiPoint objects should
>> be undefined, and result in a compile-time error, as this is a
>> nonsense operation.
> 
> I have something like that cooking in my "units" branch, but I'm cleaning
> up angles first.

Simon,

What changes are you planning for units and when do you expect to have
this done?  I just branched myself to port the schematic internal units
to 100nm in preparation for the new file formats so I'm sure there is
going to be conflicts.  If you are almost ready to merge, I can wait but
I'm ready to get started on this so I would rather not wait too long.

Cheers,

Wayne

> 
> Plan:
> 
>  - create strong types for angles and orientations [done]
>  - literal handling with unit suffix [done]
>  - replace all instances of angles in the codebase [under way]
>  - drop code to support angles expressed as doubles, ints, ...
> 
> Replacing points will be too big to do in a single commit, so:
> 
>  - create strong types for lengths and points [needs rework]
>  - literal handling with unit suffix [mostly done]
>  - compatibility code for automatic conversion to existing formats [mostly
>    done]
>  - piecewise replacement of existing coordinate code
>  - remove compatibility code
>  - remove old code
>  - remove -DEESCHEMA, -DPCBNEW etc.
>  - merge pcbcommon into common
> 
> The way I went with my approach was that there is a length class that
> expresses a 1D length in either nanometers. A separate class does the same
> for pixels.
> 
> 2D coordinates have a template parameter for the underlying 1D type, and
> for the origin point they are relative to:
> 
>  - no origin
>  - (0, 0)
>  - current reference (set with the space bar)
>  - auxiliary axis (set with the aux axis tool)
> 
> Adding and subtracting then makes sure origin points are consistent, and
> multiplying with the current zoom level converts between world and screen
> coordinates.
> 
> The initial implementation went a bit wrong because the angle handling
> needs to be done first -- the transition requires adding a new coordinate
> type parallel to the existing ones, which also requires a full set of
> Rotate* functions (degrees as double, tenth-degrees as double,
> tenth-degrees as signed int, radians as double), so reducing all of these
> to one makes this manageable.
> 
>    Simon
> 
> _______________________________________________
> 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
>