Lorenzo Marcantonio wrote: > I completely disagree. This is too complex for what we want... in fact > OOP most of the time only complicates life but that's IMHO:P
Strange to hear this from active developer... At first, don't you think, that if some programmer make his life complicated using OOP it's only programmer's problem, not OOP problem. End even if most of the programmers do so it does not make it OOP problem ever. :) Second, it seems I happened to joke you, there's no real OOP:), just exploiting "C++ view of OOP". The class (ok, data type) is made to avoid mixing between nondimensional numbers and lengths. > In the past the best way do defeat the issue was agreed to be the common > divider, something like 200nm or such. Just use it instead of the > current decimil and fix the scaling factors in the conversions (which > are mostly in the common/ code). Voilà, metric kicad with no rounding > issues... Is there any contradiction with something previously said? No, there's just a C++ construct incorporating storage and length conversion facilities. Would you think lots of #defines and bulky c-macro-style code would be better? When it implemented all the lengths should use defined class so have same scale factor. And finally, did you try to do your "Voilà"? Find all the scaling code with hard-coded constants (254's, 3937's and many weird others), fight integer overflows? Do it all in only ints without idea how to decide where are mils, decimils, millimeters in all whose variables? I did this, and say, it's not so simple as you imagine. My approach is seem to be most clear and bug-avoiding one i can work out. Do you know better one? But why did not you already proposed it? ;) I commited a file 'include/length.h' which implements the LENGTH class; it's not included anywhere yet. You an all can see it now. This class acts mostly like ordinary numeric value (+ - * / etc work fine). Also there's LENGTH_XY which is 2D version, and analogous to wxPoint/wxSize. > But IMHO it should be done *together* with the new file format so to > have only one format conversion to do... i.e. traditional kicad in > decimils and SWEET/sexp/whatever in nano units... Don't you think nano development should be *started after* SWEET/sexp is done? ;) -- --- KeyFP: DC07 D4C3 BB33 E596 CF5E CEF9 D4E3 B618 65BA 2B61 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
