kicad-developers team mailing list archive

["Reece R. Pollack" <reece@xxxxxxx>]

So _now_ it occurs to me that what I should have done was create classes 
derived from UNIT_BINDER that handle the different types of data (X-abs, 
Y-abs, X-rel, Y-rel) and instantiated those, rather than adding a 
parameter to the UNIT_BINDER class.

However, that would have also required changing UNIT_BINDER to accept 
and return /double/ values rather than /int/ to avoid the /int/ -> 
/double/ -> /int/ -> /double/ conversion sequence formatting for 
display, and /double/ -> /int/ -> /double/ -> /int/ conversions parsing 
from display.

Maybe I'll do that another time. Too many changes too late for this 
iteration, I think.

On 5/26/19 11:01 AM, Reece Pollack wrote:
> The specific problem with UNIT_BINDER is that it doesn't know what 
> sort of data it's handling. It could be a value like a track width 
> which shouldn't be altered,  a relative coordinate delta which may 
> need a sign flip, or an absolute coordinate which needs both 
> translation and sign flip. Nor does it know whether relative or 
> absolute coordinate is an X or a Y axis. Thus it must either have a 
> parameter identifying the type of data it's handling or a different 
> set of methods to transfer that data in or out based on the type. I 
> chose a constructor parameter, and I chose to pass an object 
> implemented to handle that type of data.