← Back to team overview

kicad-developers team mailing list archive

Re: Converting KiCAD to metric units: The approach

 

On 06/23/2011 02:21 PM, Vladimir Uryvaev wrote:
> В сообщении от Четверг 23 июня 2011 18:47:02 автор Dick Hollenbeck написал:
>> 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.
> Y = y;
> where would be
> Y = y/unit;
> is the simplest one which will be catched. Ok, it is easy to see. How about 
> screen coords?

Its not clear to me what you are saying here.

> Y = y*zoom;
>
> Don't you see you missed something?
>
> More on the screen:
>
>     int xscreen; // screen coord
>     int x; // physical coord
>     ...
>     Draw(pen, x...
>
> Still easy to find in hundreds of line code? Imagine, that errors are in the 
> gerber IO or similar else.
>
> All they will cause compiler error with my approach. With ints it should be 
> traced, where's it which takes from minutes to hours of precious programmers 
> type.
>
> Class approach taken from one old good design principle: different kind of data 
> shoul have different data type and will not be easy interchangeable. It's not 
> my invention. it is widely used everywhere.
>
> Even having typedef for specific kind of data (while not guarded by compiled) 
> is also widely used and it seem to good practice.
>
> In the aspec of converting: say, I looking on something like:
>
> wxPoint m_Pos;
>
> It contains some physical point in decimils. I going to trace all dependencies 
> on it and fix the code accessing it. How should I do this? text search and 
> replace? Lots of occurences, most of them is not I need. No, i'll just change 
> it type and run the compiler. Voila! All I searched for is marked by Error.
>
> When I fix the code, I put type conversion there. What if I missed something? 
> It will just be an compilation error. It WILL NOT compile ever until I fix it 
> all.
>
> But what if it is still an int? Are you sure you remember all the places 
> you're already fixed, and places pending the fix? I'm not.
>
> That's the reason.
>
>> I think a nice way to do a conversion is to call a function.  I don't think
>> hiding the conversion in an operator overload or constructor is superior to
>> calling an obvious conversion function such as:
>>
>> 1) mm2internal()
>> 2) mil2internal()
>> 3) internal2mm()
>> 4) internal2mil()
> Hey, don't you joking? It's the one of the worst examples of code reuse i ever 
> seen. 


It's hard to take a statement like this seriously.


> I dont even realise if it better than just hardcoding a constant. :)
>
> Say, we have set of usable units. They are (currently used):


No.  I won't say we need 4 types of units.  I said we need two sets of
engineering units.  So why now would I now say we have 4?

Java explicitly avoided typedefs so that you could see you had an int, when you
had an int.  There is much to be said for that.  I happen to like that about
Java.  I hated virtually everything Microsoft introduced to the software world,
including DWORD, and all kinds of crap like LENGTH.



> - mm;
> - inch;
> - mil;
> - decimil;
> You suggest me to write 8 functions, twice the number of units! EIGHT 
> functions doing nothing more than multiply or divide by constant.
>
> As they do not make life easier, they make life harder. Say, I want to display 
> several quantities, having unit choosable [cm/mm/inch/mil]. HOW should I write 
> this:
>     switch(chosen_unit) {
>     case INCH;
>     display(internal2inch(x));
>     break;
>     case MM:
>     ...
>     }
>
> Do you like it? I'm not.
>
> First better soultion is to make this function take second parameter
>     unit2internal(what, unit_from); // use it like x = (x_in_mm,millimeter)
>     internal2unit(what, unit_to);
>
> Only two functions (and several constants, one per unit).
> Or even one function, taking 3 paramters:
>     unit2unit(what, unit_from, unit_to);
>     q = unit2unit(q_in_mm, mm, internal_u);
>
> Now, just take a look inside. It is just a division and subtraction:
>
>     int unit2unit(int what, int unit_from, int unit_to) {
>         return what * unit_from / unit_two;
>     }
>     #define internal_u 1
>
> Will it change sometime? Sure, no. So why shouldn't I write just
>     q = q_in_mm * millimeter;
> instead of
>     q = unit2unit(q_in_mm, millimeter, internal_u);
> or
>     q = mm2internal(q_in_mm);
> I wonder why I shouldn't. It is clear and intuitive. It works without need of 
> external function. It is flexible. It is optimized perfectly.
>
> Prove me your functions are better than my * and /.

You can put your * and / in my functions. 


> Ater all, is you think it is so simple, why didn't you already made it all?


Why have I not painted my back porch?


> As I stated before my class can be easily switched to a simple typedef. At the 
> end of conversion, if you like.

int is fine, without the typedef, that way I don't have to go unwrap LENGTH,
mentally or by compiler.



> //-
>
>>> I do not ever see a need to keepmore than one unit supproted.
>> Where?  What context are you talking about?  I think we need to store board
>> and footprint files in both imperial and metric both.
> I'm about saving/loading.
>
> We do not need it. It gives us nothing. Does not matter what units are in file, 

Actually the mils and the mm are human readable.  That is their value.   The
ASCII Kicad files have always been able to make this claim.  Storing things in
nanometers will lead to big numbers, and there will be a lot of zeros.



I think its time for Jean Pierre to jump in and offer some leadership here.

It seems there is no agreement to be reached here. 

When this happens to Linus, he simply excludes stuff from his own tree.  That is
Linus' real source of power.

Perhaps Jean Pierre will have to decide if he wants every int wrapped in a
class, only to have the compiler spend nano-seconds on each instance unwrapping
it at compile time, and then who knows what overhead at runtime only to store a
silly integer.




Follow ups

References