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 : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
