kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote:
> Mid-term in the wrong direction.  Kicad is like that...

Look. I have this board due to fabrication for the end of month.
I simply can't implement the whole object model in time *and* do the
board layout to produce it.

It's a human resource allocation problem :D it's a temporary solution
but *it works*; the optimal solution is not useful if it's not available
for use.

The kicad object model is not perfect (and anyway everyone has its own
idea of perfect model), but kicad itself is not exactly small. Probably
only you and me know exactly how many time a layer type is
used/iterated/converted in pcbnew:P

Also if you remember even my type cleanup was partially rejected
becaused they wanted to keep layers as 'simple integer'. And if was
actually a little more than a typedef. A mergeable layerset
implementation would require a full layer class and other objects (as
you said, correctly), but I simply don't think that would be accepted by
the 'steering commitee' of kicad:P I don't like, too, the asymmetry
between the board layer structure (renameable) and the module one (the
'standard english'). Going generic requires a pervasive layer container
(call it stackup or whatever) and layers would then coordinate with
their own container, or something like that.

In short, I perfectly agree with you but I don't think is feasible to
propose such a big change (which is mostly a management issue). I almost
got lynched when I proposed switching to enums from #defines.. (reason:
you have to type the containing namespace, too)

> If you consider gcc-specific features a standard...

int64_t is ISO C++, not gcc. long long is a gcc extension, but AFAIK gcc
is the only target for kicad on all platforms.

> converted back.  std::set was used to represent an arbitrary set of

I tought about std::vector<bool>, std::set<'int'> is a little slower but
good anyway (would be more useful if layer numbers were sparse).

Lack of literals would need the introduction of a quantity of
predicates, but it's doable. Many of these predicates are already there,
anyway...

> funner stuff was the simulated annealing for location of items in the
> vicinity of another.

? What would be that for ? hit testing or drc? and why annealing instead
of a circular sweep or similar?

-- 
Lorenzo Marcantonio
Logos Srl