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 : [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
