kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/6/2010 9:40 PM, Dick Hollenbeck wrote:
> On 10/06/2010 08:17 PM, Dick Hollenbeck wrote:
>> On 10/06/2010 06:47 PM, Wayne Stambaugh wrote:
>>   
>>> On 10/6/2010 6:28 PM, Dick Hollenbeck wrote:
>>>   
>>>     
>>>> On 10/06/2010 03:27 PM, Wayne Stambaugh wrote:
>>>>     
>>>>       
>>>>> On 10/6/2010 3:17 PM, Dick Hollenbeck wrote:
>>>>>   
>>>>>       
>>>>>         
>>>>>> On 10/05/2010 07:04 PM, Wayne Stambaugh wrote:
>>>>>>     
>>>>>>         
>>>>>>           
>>>>>>> On 10/5/2010 10:33 AM, Dick Hollenbeck wrote:
>>>>>>>   
>>>>>>>           
>>>>>>>             
>>>>>>>>             
>>>>>>>>               
>>> <<< snipped >>>
>>>
>>>   
>>>     
>>>>>>     
>>>>>>         
>>>>>>           
>>>>> I wonder if it would be beneficial to create a LIBRARY_SOURCE for reading the
>>>>> existing library file format to maintain backwards compatibility.  The source
>>>>> code already exists to read these files.  Granted you wouldn't get any of the
>>>>> fancy new features like inheritance but you at least would not loose your
>>>>> current investment.  I don't know that an end around the LIBRARY_SOURCE API
>>>>> would be necessary.  I'm sure you could create a LIBRARY_SOURCE object that can
>>>>> provide writing so a derived class like OLD_KICAD_LIBRARY_SOURCE could even
>>>>> write library files in the old format ( not that you would want to ).
>>>>>   
>>>>>       
>>>>>         
>>>> I'm not a fan of adding write access functions to the LIBRARY_SOURCE
>>>> abstraction, not in any case.
>>>> I think you need to do an end run, there's only one special case of a
>>>> library source that is writable.
>>>>
>>>> This is where I claim KISS.
>>>>     
>>>>       
>>> Fair enough.  I was just thinking if there was one case where we would
>>> want to write there may be another one that we haven't considered at
>>> this point.  I trust your judgment on this one.
>>>
>>>   
>>>     
>>>> Moving on to what the LIBRARY_SOURCE has to do, it has to give you the
>>>> sexpr text in the COMPONENT or symbol, shown below.
>>>>
>>>> class COMPONENT or SYMBOL (i.e. CODE_FRAGMENT)
>>>> {
>>>>     pins              // pin table
>>>>
>>>>     properties        // aka fields collection
>>>>
>>>>     graphics          // graphics primitives
>>>>
>>>>     std::string    sexpr;
>>>> }
>>>>     
>>>>       
>>> My original thinking was that SYMBOL would be one level lower in the
>>> food chain and not contain any properties.  The COMPONENT object could
>>> include one or possibly more SYMBOLs.
>>>
>>> class SYMBOL
>>> {
>>>     pins                // pin table
>>>     graphics            // graphics primitives
>>>
>>>     std::string         // sexpr
>>> }
>>>
>>> class COMPONENT
>>> {
>>>     symbol              // symbol table
>>>
>>>     properties          // field table.
>>>
>>>     std::string         // sexpr
>>> }
>>>
>>>   
>>>     
>> I like that.  Here's a subtle twist on the idea:  A COMPONENT could
>> simply lose the symbol table and replace it with pins & graphics
>> containers (= table = list).  Then during the parsing, when encountering
>> the
>> symbol's (pin) and (line) tokens, the parser simply puts those into the
>> including COMPONENT's pin and graphics containers additively, as C++
>> binary objects of course.  This way you only have one pin containere
>> when you are all done, and one graphics container in the including
>> COMPONENT.  This makes hit testing, binary searching, and drawing easier.
>>   
> 
> It occurs to me that if you had the assignment operator in place for
> COMPONENT or copy constructor, you could simply assign to the containing
> component when seeing an "inherit" token using the base component.
> 
> (component A
>  (inherit component B GUID)
>  (pin 12 ...)
>  (property NAME VALUE (offset X Y) (orientation 0)(font FONT)(visible NO))
> )
> 
> 
> 
> So while parsing A I see that *for B*:
> 
> a) B had its deferred loading triggered from the LIBRARY_SOURCE (= you
> have the sexpr), and
> 
> b) B has already been parsed into binary form, then
> 
> you can implement the inherit token while parsing A simply by using the
> assign operator or copy constructor as the initial part of the parsing
> A, then you simply have to handle what follows incrementally.
> 
> 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.  Most
of objects that draw text use multiple inheritance.  These classes will need to
be refactored to do something with the extra EDA_TextStruct inheritance.  The
quickest solution would to embed them in their respective objects.  The more
elegant solution would be to push them further down the stack so single
inheritance can be used all the way up the chain.  This solution has the
potential to break a lot of code in PCBNew.  The pragmatic approach may be to
embed EDA_TextStruct it into the library and schematic drawing objects until
the appropriate PCB drawing objects can be cleaned up.  I can do this as part
of the refactoring work I was planning to do to the component library objects.

Wayne

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