kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----

> From: John Beard <john.j.beard@xxxxxxxxx>
> To: Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>; Kicad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Cc: 
> Sent: Wednesday, May 7, 2014 9:44 AM
> Subject: Re: [Kicad-developers] Forward-compatibility in s-expression formats
> 
> On 06/05/14 23:18, Tomasz Wlostowski wrote:
> 
>>  How about about adding a generic attribute set for each part, stored as
>>  a list of type-name-value entries:
>> 
>>  (part xxx
>>      (attribute "simulation_model" (string "xxxx.cir") )
>>      (attribute "part_reference_farnell" (int 123456 ) )
>>  )
>> 
>>  Such scheme would not only allow adding a vendor P/N to each symbol, but
>>  also simulation models, high speed constraints (length, impedance) and
>>  so on.
> 
> Yes, this is a good way to do it, we'd just need to define some grammar 
> of "types" to allow parsing, and everything else is self-describing. 
> It 
> does seem a little verbose, but as Lorenzo said, maybe it's not possible 
> to add unknown elements without breaking everything, and we'd have to go 
> down a road where new elements always say exactly what they are.
> 
> I suppose one question is in that case, why wouldn't all elements be 
> self describing, rather than having the "old" elements like 
> "at" having 
> some implicit type, and new elements like "location" (say) needing to 
> say "(location (coords 3.3 3.3))".
> 
> Then again, if you ever come across a data type that we didn't have the 
> foresight to include at the start, you'd have to munge it into a string 
> or other primitive to express it, or you're back to square one.
> 


I don't see why there would be a problem even without types since the expressions are bounded by parentheses. You can read all data from an expression and discard or store it without having any idea what it is.

As for conflicting uses, users can always be required to prefix nodes with something like u_ to ensure that there is never a conflict with future builds of KiCad.

- Cirilo