kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

>> My proposal is: handle/save *everything* in nano/metres whatever like
>> the decimils today. Unit conversion is relegated only to UI, which, in
>> fact, is handled by 3-4 function in all (I studied that when I've done
>> the 'universal unit' patch which allow to type 3,2mm in an edit box even
>> when units are set to imperial; apart from the converter itself there were
>> less than 50 lines of changes IIRC, done the work in about a day). So you
>> *could* build your class infrastructure but at the end the
>> conversion functions would be called only 4 times in all the kicad
>> sources (and most probably these call would be in the same source file).
>> OOP is bad when functional is sufficient (yes, not even imperative, it's
>> a functional solution, too:D)
> If you like functional/imperative paradigm it's you own opinion. I even prefer 
> to use paradigm that give me better soultion.
>
>> OK, my proposal instead is a simple double type (you can typedef it as
>> 'metric_size' if you want) and 2/4 functions which are already in
>> place... also you can already pass it to geometric routines like kbool
>> or boost::polygon (don't remember the name) as is (your LENGTH class
>> would need getter and/or cast operators I suppose to interoperate
>> correctly).
>>
>> My bottom line is: why keeping the unit along the datatype when
>> everything *except* the user don't mind about the unit itself?
> Because one day man invented type checking, and i gonna exploit it to do unit 
> conversion.


Vladimir, please show us an example where your class causes the compiler to
catch a problem that would be un-detected without it.

I don't see it *yet*, and like Lorenzo, I have leanings toward what I perceive
to be the simplest solution.