kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

В сообщении от Суббота 19 ноября 2011 23:43:46 автор Dick Hollenbeck написал:

> The key postings which illustrate my point and my understanding that there
> was no concensus reached were these:
> 
> The first one carries the most weight, because it is from Jean-Pierre:
> 
> 1)
> http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg01887.
> html
> 
> And my objections:
> 
> 2)
> http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg01878.
> html 3)
> http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg01880.
> html

"...I do not see the advantage..."
"I don't see it..."
"Its not clear to me..."
"Java explicitly avoided typedefs..."
"I hated virtually everything Microsoft introduced..."

Above are not look like an argument but like an personal opinion and/or 
attitude. It is not an object for a discussion.

You do not see an advantage, but I see. I need for me to track anything 
related lengths (with the help of a compiler).

Typedef, as any other tool, may help and may hurt. This depends on how you're 
using it. DWORD and other typedef stuff was developed long before the Windows 
has come. Mostly they're used where portability is an issue, because 'int' is 
not so portable thing: name 'int' says only that it is an integer number of 
range not less than -65535...+65535. But for portability in most cases much 
more information needed, that's why in C99 (not C++) '[u]int*_t' was appeared 
(see, they're just a typedefs). It is not the case in ADA where integer limits 
are set explicitly, but it also have typedef-like syntax, just to define limits 
only once. In Java AFAIR, typedef is superseeded by inheritance (in c++, int 
cannot be inherited, only typedef'd).

OTOH if one specific technique made a rule it starts to hurt much, as happened 
with Microsoft and their typedefs and hungarian notation (it is also not bad 
then used wisely). Intention of MS's typedefs was to keep system call 
parameters same machine type while in transition from 16 bit to 32 bit (int 
and pointer are different when compiled in 16 bit and 32 bit modes!). Long time 
only 32 bit machines rule the world and many programmers did not imagine that 
int and long can have other width than 32 bit. But it can and it causes 
portability issues.

My case is another. The value which LENGTH type carry is not an integer. It is 
a physical length and it behave like a length, not like an integer. You do NOT 
need keep in mind that machine stuff stands beyond its name. It is convenient 
for me as a developer and switch its type just editing single line and see, 
what's happen. If I suspect there are overflows somewhere, I may switch to 
int64 or LIMITED_INT (which I introduce) and quickly catch them. If I suspect 
roundind errors I may switch to long double (or even reload basic operations 
to track all roundings in log!). When my work is finished I just switch back to 
simplest and fastest type.

That's why I'm friend with typedefs.

In many cases all this stuff looks like:

    #ifdef NDEBUG // release
    typedef int X
    #else
    class X ..... (all that debug stuff)
    #endif

Am I so clear now in that I do?

> However I agree with you that we all could have been clearer.
> 
> In my mind, when Jean-Pierre objects to something, I tend to take that with
> a fairly heavily weighted factor, so my lasting perception of the
> conversation was obviously different than yours.

When in discussion, personality should not be weighting factor, only the sense 
of arguments. After the discussion authorized person makes the decision.
If you decide, that I should not do what I do in kicad, i will not do it there 
(i'll do it somewhere else). If you decide that it is not needed in KiCad or 
have to be done in another way, i understand.

I do not know your level of knowledge and expirience and you all do not know 
my, so we all can not decide how strong our arguments should be.

> Putting that behind us now, are you willing to reopen the discussion and
> answer some questions by others and myself?
> 
> > It seems I understood
> > incorrectly what should I do, and what shouldn't.
> > 
> > В сообщении от Пятница 18 ноября 2011 21:23:21 вы написали:
> >> 1) Regarding the use of "class wrappers for integers", you never
> >> completed the argument to a point of having built a consensus.  Both
> >> Jean-Pierre, Lorenzo, and myself expressed disagreement towards this
> >> plan in the
> > 
> >> following thread:
> > I do not realize what sort of argument you're want from me. Is it known
> > method for you to encourage the compiler to catch possible bugs?
> > 
> >> http://www.mail-archive.com/kicad-developers@xxxxxxxxxxxxxxxxxxx/msg0187
> >> 9. html
> >> 
> >> Independent of how good or bad the idea is or was, we now have a
> >> political problem, and that is that we currently think you have some
> >> "team player" issues to improve on.  Perhaps an apology and a
> >> continuation of the original conversation is needed.
> > 
> > Seemingly I'm bad 'team player'. I apologize.
> 
> Thanks for making this effort.  We are in fact a team, and what we need are
> team players, especially in those positions which have commit rights to
> the testing-branch.
> 
> >> a) Star * to be after LENGTH_UNIT_DESC not before UnitDescription()
> >> b) { bracket to be on its own line after first line of function.
> >> c) switch() needs whitespace around the aUnit on both ends.
> >> d) { brack to be on its own line in switch.
> >> e) switch indenting of cases is wrong, cases to be at same level as
> >> switch() f) single line comments are to be C++ not C style..
> > 
> > bcde) was my fault, I still did not spent 15 s to reformat 5 lines of
> > code, but... It seems my eyes cheat me, but I still do not see the
> > *rules* for a) and f).
> 
> a) & f) are in the coding standards document, but there is also the tens of
> thousands of lines of code in the project which already act as examples.

Can you cite the *rule*, please? Examples are not rules, though.

My 'native' style too different from what KiCAD use but I believe we all should 
be tolerant to others. I cannot take as an argument that 'makes it difficult to 
see' (Wayne wrote), because many people (outside KiCAD project) write like me 
and read such code and have no difficulties.

However I do not intend to break or change the rules.

> I saw this bug in a recent revision pertaining to
> 
> Clearance 40.000000
> TrackWidth 40.000000
> ViaDia 180.000000
> ViaDrill 100.000000
> uViaDia 200.000000
> uViaDrill 50.000000
> 
> This raised an alarm with me.  I don't like unnecessary trailing zeros, in
> any case.

I cannot reproduce it. If it is still not work as expected, I apologize.

> > p. s.
> > Do you want to know my (and russian KiCAD developers I met today) point
> > of view on KiCad sources? Do you find easy to read well formatted
> > spaghetti like code?..
> 
> Yes to the above, but only if you think this would be helpful to the
> project, or to our perception of you.

I do not intend to offend any of developers, but all sad below is what we 
agree in.

Altough too much effort in whitespaces, linefeeds and letter case, in general 
kicad source is bad designed, overcomplicated, ineffective, and thus need much 
rewrite and refactoring.

For example, that's I've found.

* Several definitions of macros abs, max, MAX, min, MIN and similar in different 
headers, and sometimes sources (already fixed in my last commit), it seems they 
are not alone.

* Much stuff related to class internals spreaded all around sources, like this 
one dealing with TEXTE internals found in MODULE method:
            pt_texte = (TEXTE_MODULE*) PtStruct;
            pt_texte->m_Pos.y -= m_Pos.y;
            pt_texte->m_Pos.y  = -pt_texte->m_Pos.y;
            pt_texte->m_Pos.y += m_Pos.y;
            NEGATE( pt_texte->m_Pos0.y );
            pt_texte->m_Mirror = false;
            NEGATE_AND_NORMALIZE_ANGLE_POS( pt_texte->m_Orient );

* switch() where polymorphism fit much better (similar to above).

* Lots of hardcoded constants throughout the code.

I understand that much of it is not a result of someone's incompetence and a 
result of long-long 'evolution', but in my opinion it retards KiCAD 
development too much.

I think it would be best if lead developers take all in their 
plans, e. g. by creating nice blueprints which we all will take cue from.

-- 

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