>> This I think can only be done using single inheritance, but a long >> lineage of single inheritance will still work. >> > We currently have some places in the drawable object stack that will require > some rework if you want to use single inheritance and a copy constructor.
Wayne, I was speaking of single inheritance with respect to the sexpr, and was not speaking about C++ objects yet. Since the field/property support needs this FIELD_USAGE concept, it is unlikely that the existing TEXT thingy you mention will be re-usable. This is why I did not want to get too tightly bound to old ideas in the underlying datatree just yet. Attached is the result of the first 1/2 hour of work. Sorry I did not get more time this weekend on it. More over the next several days. I think we need to take a final look at the keywords (i.e. nouns) we want to use, and start to set them in place. I have this nagging feeling we are introducing an unwanted swapping of component and part. Please consider the value of using "part" in the parts list and libraries, and then component or comp in the schematic to indicate an instantiated part. Does this dovetail with the generic export? If not, what do we do? part and comp are both fairly short keywords and they both are pretty explanatory. Also, what do you think about the element "at", such as (at X Y ANGLE) as a nice 3 value tuple? In the LIBRARY which is a cache, we will have to have instances of a small container object which holds the state of its "part/component", loaded, parsed, or not. This little container is initially present with the part's name, but not much else, since in the remote case, we do not want to load everything unconditionally, initially only the names, and defer loading until later. BTW, this is why the directory type listing functions are important, and the FindPart() which takes a single query string. I envision a small domain specific language to specify the query string. The LIBRARY_SOURCE implementation has to support searching (as well as the LIBRARY, which I have not started yet.) These are the ideas I will try and embody in my next contribution, focusing on the functions, not the internals of each object quite yet. Dick
typedef std::string STRING; typedef std::vector< STRING > STRINGS; const STRING StrEmpty = ""; NRVO described: http://msdn.microsoft.com/en-us/library/ms364057%28VS.80%29.aspx Even with NRVO provided by the compilers, I don't see it being as lean as having the LIBARY keep an expanded member STRING for the aResult value. So I am heading towards passing STRING* aResult and STRINGS* aResults. Rather than returning a STRING. class LIBRARY_SOURCE { virtual void ReadPart( STRING* aResult, const STRING& aName, const STRING& aRev=StrEmpty ) throw( IOError ) = 0; virtual void ReadParts( STRINGS* aResults, const STRINGS& aNames ) throw( IOError ) = 0; virtual void GetCategories( STRINGS* aResults ) throw( IOError ) = 0; virtual void GetCategoricalParts( STRINGS* aResults, const STRING& aCategory ) throw( IOError ) = 0; virtual void GetRevisions( STRINGS* aResults, const STRING& aName ) throw( IOError ) = 0; virtual void FindParts( STRING* aResults, const STRING& aQuery ) throw( IOError ) = 0; }; class LIBRARY_SINK { virtual void WritePart( const STRING& aName, const STRING& aSExpression ) throw ( IOERROR ) = 0; };
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
