> All in all it seems like a very sound concept. It will be interesting > to see how it works in practice. > > Wayne >
Wayne, You could zero in on the grammar for the component, and symbol if you still want that property-less grammar element. A symbol element/token could exist if you really want it, and it can control the grammar (which would say explicitly exclude properties) but still parse down to a COMPONENT in C++ terms, with an empty property table. Also, after having just done that example in my previous posting, I see that the number of child elements for a property are quite involved. Possible simplification: optional most common defaults which need not be supplied? We really have to keep the notion of "this is source code and it needs to be very human readable" in mind. I could be working on the *.h file while you get the component grammar done and parsing. Formatting, the reverse of Parsing ---------------------------------- What is interesting about this design is that to "format" the COMPONENT to sexpr, you simply have to output the already existing sexpr. I can think of no case where the sexpr does not already exist, because in every case the component was generated by parsing from the sexpr. The only thing to think about there is beatification and indentation. We could have the object specific parser like we discussed, and we could also have a generic parser that build a token tree kind of like the XNODEs and then simply uses the XNODE save function to "beautify" the token tree back into string form. We never have to generate the sexpr from the binary component object's graphic's and pins itself, and this is remarkable I think. We always simply have the sexpr from which we generated the binary, so that will always be good enough ? Well wait, what if we still want to support graphical editing?, then this idea gets trickier. And keeping track of what you inherited from could easily get lost. I had mentioned earmarking the (line) (pin) and (property) binary elements with their GUID origins. This could put them off limits to graphical editing of the containing component. There are still some conceptual holes to be plugged if we want to support both inheritance and graphical editing in the same component. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
