kicad-developers team mailing list archive

[Alex G <mr.nuke.me@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/06/2010 09:37 PM, Lorenzo Marcantonio wrote:
> On Mon, 6 Sep 2010, Alex G wrote:
> 
>> I don't use kicad comercially, at least not yet. Eye candy or not, the
>> truth of the matter is that the 3D view is a unique feature to kicad,
>> and is not worth neglecting.
> 
> Never said to neglect it. I was explaining why I didn't even mess with
> the 3d models. I *have* used boxes for interference checking, though.
> 
The 3d models are a pain in the gluteus maximus to make, I agree, and I
don't blame anyone for not wanting to get their hands dirty with them.
The question is on striking a balance between this and not having them
left out.

>> My instinct would be to find gluPerspective and combine it in a switch
>> with glOrtho, but I haven't fully digested the way kicad does it. One
> 
> That's exactly the way it should be done.
>
Great! The next time I open the kicad source, I'll look for where to put
that. I think I've already figured out how to add buttons to the GUI :p .

>> thing I generally hate about C++, is people not using this-> when
>> accessing members of the current object. It would make things so much
>> more clear, and it's the reason I'm slow at digesting kicad.
> 
> It's not idiomatic in C++ where encapsulation is somewhat strong.
> I think you could be the only one proposing said syntax :D (also, there is
> one exception: this isn't available/reliable in constructors and
> destructors).
> 
Constructors and destructors are a different story, and the reason we
have (well, C++ has) initialization lists, which make things explicit.
Either way, I am not trying to propose this syntax. I'm simply
describing the current one as a minor grudge.

> Maybe you're coming from an OO model where the this/self pointer is
> explicit (like perl, lua and many others). Remember it's from a family
> of languages where terseness is valued. CLOS on the other hand has
> method completely external to classes (it does inheritance with
> polymorphism... sort of:)
> 
> OTOH there are many conventions, more or less useful or followed, for
> example the m_ for members and g_ for global, it's pretty used in kicad.
> I find more difficult to find from what parent a member comes...
>
And that is yet another awful convention. Efficient, I admit, but ugly,
awful, and intolerable. It's a C-style convention. Prefixing
variables/members is frowned upon in many C++ books.
This reminds me of a discussion on the list of people "programming on
their hands and knees" by "feeding C code to the C++ compiler".
Disclaimer: this is entirely my opinion, and it does not constitute a
request, a proposal, a suggestion, or any other attempt at code reform
in kicad, or any other source code.

> Another rationale is: since there should be no global variables (or at
> least few of them), you can see the function parameters so everything
> that's not a parameter is a member. Too bad there are soooo many
> non-static globals in kicad :(
> 
Yes, I compile a list of the parameters in my head, and whenever I see a
variable, I compare it against the list to determine whether or not it
is a member. Why does programming have to be so complicated? If I can
tell myself that this-> variable is a member, but that other one isn't,
and without having to alter the variable names to do that, why shouldn't
I? (Well, I shouldn't, because if I ever end up writing a patch, it will
be rejected by Dick). :P
The above disclaimer still applies.

> And anyway there is one style for each programmer:D
> 
Indeed. I am not proposing any of the above; however, kicad _does_ need
a _documented_, agreed upon coding style. At least we don't end up
getting one-line C-style comments mixed with a C++ style comment on the
next line.

Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMhfWhAAoJEL0kPHNPXJJKfksP/0pXYO8r71n/yKBsUpcHmMRd
TJWMT6Ma1GhsVuAIyHjGIb5qkx7aRE3gFAdJKiOrmzPzsQF/VKX1gahptuwMILah
lPvOtbJFJAhQN1TZym8NRYD6Zr9etZiAsE5hAmKZoxkmyenCB5CpdmidYucI1vuX
0aP5sVEZex8Z+gvAVV7DtdvoIAHCI39h952VKhAwqgEbuPuo1lt0K/GF1IhiJHX0
0uwMNerzMVSkyquJBx/+4J6PfQmKXK4UuFpeXsmhlw2imO8oYPZ21qAvlOCObaAP
Q8u1o41sW1Y8ov4SQ+s5q/SOtYFYdznS4+GkHRBO5Hcs3pP6hd0OIIpIq/fS0/xR
8AfanNWmMRV+OjVektzP/xH+yyKmifVteGF3vT/Sl0ozt/9OMvpY8b29mje8++Xy
kMbbUhWYGz7POnDblhRFIh1XUXckBJppm3cEmPOoSkG6otkjyBojxf4crFnKDDcm
wrsGp+VUGEgiWSvLXhTmxuLlsW0bfd1GXJxjcTCgzFzvdL5jM/wPQ1wdvr1zE9YQ
QGhVCkwrpaVZooDXF45oXdVg2e5ZS4QSfEsFc1Q95LpLCGPrbd5v6oKxhE7SbUCl
c0LLducQAhtKl14+zf4hiaHEHNT/Gi4airA5LnylGax7IT0kvP5JopYT+4WzWh24
rKJ9czoldIXt651wsx79
=Yhj4
-----END PGP SIGNATURE-----