kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Tue, Nov 22, 2011 at 06:05:33AM -0700, Brian F. G. Bidulock wrote:
> Looking at the code, the first thing that I did was change all
> members to private and used the compiler to force the use of
> proper accessor member functions throughout.  This is necessary
> to do the least little thing with pcbnew.  But it appears that
> the current "masters" do not like to program in C++: they make
> all members public and access them directly from everywhere.

That's false, it's only the kicad legacy... it's not the first time
public variables are exchanged with accessors; and, anyway, the whole
'accessor' thing is debated in some circles: CLOS is a way better object
model and has *no* access control to members or slots. I agree that in
C++ is customary to use accessors, anyway.

> When you try to correct it, they complain that it might break

When this? Never heard something along the lines of 'keep these stuff
public'; I'm also against globals BTW and there was consensus about
their progressive removal.

> Then they make "coding standards" that specify which whitespace
> to put around their bad code.

Well, their paren standard is funny actually :D never seen done that
way. But as a lisper I really don't see the parens:P

> These things, coupled with an accute resistance to any change
> that isn't a bug fix, makes it impossible for any experienced
> C++ programmer to contribute more than one liners to this
> project.  I experienced pretty much the same response as you
> did (but I didn't push as hard or even get commit access).

Sorry? I contributed about some 3-4 new features and I didn't see any
resistance... well, parens spacing excluded:P:P

> Others have gone their own way in the past.  It is a pity

I have a whole different font machinery in my private branch. I don't
ask for committing it because a) ISO font spacing is way different and
breaks the lib, b) I only have Latin-1 and Tech-1 repertoire and c)
I need to clean up some font license issues. That said I regularly merge
and push it as a branch, there's no need to call it a fork. When (if)
the above problem are solved I'll simply do a patchball and submit it
for review.

> Here is a short list of things that cannot be done without
> tearing out all the bad code in pcbnew:

Tearing bad code is a thing, adding overengineered bloat (the int class,
for example) is another one. Yes, I'm not a fan of OOP :D

-- 
Lorenzo Marcantonio
Logos Srl