kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

>> 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;

};