← Back to team overview

kicad-developers team mailing list archive

Re: exploiting human readability

 

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.

Dick




Follow ups

References