kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Wed, Jul 16, 2014 at 11:29:58AM +0200, Tomasz Wlostowski wrote:
> Do you mean storing everything in a flat hierarchy and getting rid of all
> links/pointers between items? This would be great (Alfons uses such model in
> Freerouter, I made it to less extent in our P&S).

Not necessarily flat, the containment hierarchy between
board/module/item is useful and it's practical to traverse it
recursively (a depth first usually would be appropriate and you don't
need to support nested modules --- altough in theory at the moment you
should:P). Also our trees are threaded so it's easy to iterate non
recursively on them...remember than most operation on the board are
simply linear list scans at the moment.

What I mean is that while a MODULE contains BOARD_ITEMs (in m_Drawings),
in general BOARD_ITEMs can't be put in a MODULE (and that's horrible
from type theory itself :P). Well, in fact BOARD is-a BOARD_ITEM and
that would made Cantor roll in its coffin...

In fact at least a DRAWSEGMENT works both in the board and in a module.
I remembered different types.

Other than that, why we need a difference between TEXTE_MODULE and
TEXTE_PCB? why TRACK is not a DRAWSEGMENT (or if the is-a doesn't hold,
why can't we have a TRACK in a module? I know, the track list need to be
kept sorted by netlist, it was a rethoric question) some refactoring in
the class hierarchy/usage could help with these problems and allow other
proposed extensions (like zones in modules). So in the end the irregular
type system gives issues (not very harmful ones, at least)

-- 
Lorenzo Marcantonio
Logos Srl