kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

В сообщении от Четверг 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?

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. I dont even realise if it better than just hardcoding a constant. :)

Say, we have set of usable units. They are (currently used):
- 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 /.

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

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

//-

> > 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, 
while we mantain required precision, it would save and load prefectly.

-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61