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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp