kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/11/2010 10:58 AM, Dick Hollenbeck wrote:
> 
>>> 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.

I think this needs to be defined as soon as possible.  If we don't have a clear
concept of when a component becomes a part and where and how they are used we
will have a difficult time having a sane discussion about their implementation.

> 
> Also, what do you think about the element "at", such as (at X Y ANGLE)
> as a nice 3 value tuple?

I'm assuming this is the component version of "at" and any mirroring would be
applied at the schematic level after it is placed in the schematic.

> 
> 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.)

It looks reasonable so far.

Wayne

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