Even though I'm not quite ready to start discussing the new file formats just yet, here a few of my thoughts on inheritance:
Inheritance will be implemented in a second phase during the development of the new file formats and possibly pushed into the version 7 release. The reason is that there is currently no support for inheritance in the schematic object code so that would have to be written first. Existing symbol libraries would be converted as flat symbols (no inheritance). I'm not interested in trying to write code to analyze existing symbol libraries and try to map them to a coherent inheritance model. It would be too much work for too little gain. Only new symbol libraries could be created using inheritance. Inheritance would make for cleaner symbol libraries but not so much for the schematic object code. It may turn out the inheritance concept is not worth the effort it takes to implement it and we abandon the idea. Nothing is set it stone at the moment. Inherited symbols would have to be flattened before they could be embedded into the schematic file. Otherwise, modifying an inherited symbol would change all of the inherited symbols in a schematic which may not be what the user expects or wants. Having to flatten inherited symbols is a potential argument for not implementing them. I expect the implementation of the new schematic file formats to be a bumpy ride. We are making a fundamental paradigm shift (embedding symbols in schematic files), adding a lot of new functionality (gate/pin swapping, netclasses, etc.) and changing the internal units to metric. I don't think the for one second that the new schematic file formats are going to be a slam dunk. On the contrary, I think it's going to be more difficult than the effort required to rewrite the footprint and board file formats. Those of use who were around for that remember just how much work was involved. Cheers, Wayne On 7/16/2018 10:28 AM, Rene Pöschl wrote: > My guess would be maintainability. > Having some way of sharing parts of different symbols with each other > makes it way easier to manage large libs. (Nobody would be forced to use > these features but they can make live easier for library maintainers. We > could then for example provide a single nmos graphic that is then used > in all nmos symbols of the official lib. Reducing the work for both > contributors and maintainers.) > > On 16/07/18 16:24, Tomasz Wlostowski wrote: >> On 16/07/18 16:04, Jeff Young wrote: >>> Thinking more about it, we could probably auto-convert existing >>> aliases to inheritance when we read them in. >> Why do we need any inheritance at all? My only guess is to make Kicad >> even more hackerish and difficult to understand. >> >> Tom >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
