>> 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. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
