kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/16/2010 10:43 AM, Dick Hollenbeck wrote:
> On 06/16/2010 09:02 AM, Wayne Stambaugh wrote:
>> On 6/16/2010 9:02 AM, Dick Hollenbeck wrote:
>>   
>>> On 06/15/2010 06:58 PM, Werner Almesberger wrote:
>>>     
>>>> Of course, access to the names of user-defined fields would also
>>>> be useful in the absence of templates. And it would bring us one
>>>> step closer to not having to worry about slots at all. Everybody
>>>> wins ;-)
>>>>   
>>>>       
>>> You have that now.  Where are my winnings?
>>>
>>>
>>> Fields after the first 4 fixed fields are saved with the fieldnames
>>> should they be different than the default fieldname.  But discussions
>>> about file formats which are on the cusp of change and obsolescence are
>>> not interesting to me.  Wayne has designs brewing to change most if not
>>> all the eeschema file formats.
>>>     
>> Dick,
>>
>> In regards to the forthcoming file format changes, I have some more
>> housecleaning on the component library and schematic objects I would
>> like (need?) to do that will make implementing the new file formats
>> easier.  To avoid a lot of merge conflicts with what you are working on,
>> I will hold off until you have made at least your initial commit of the
>> field template code.  It looks like I'll have some free time next week
>> to start discussing and working on these changes.  I also hope to post a
>> blue print of a first draft of the new component library file format by
>> the end of next week.
>>
>> Wayne
>>   
> 
> Sounds good.   We look forward to your further contributions which are
> always appreciated.  (Plus everyone seems to like free stuff, but that
> may too philosophical...)

I think I'll try to avoid those philosophical discussions on the matter
of free.  They tend to degrade into all other manner of ugliness which I
have neither the time nor ambition to debate.  My guess is that your
philosophy on free is very similar to my own and is likely not that of
popular culture;)

> 
> A relatively painless way to migrate to new formats without changing
> totally the internal datatree is to simply introduce the following two
> methods to each major class/struct that will be a present in the files. 
> I say major meaning that not every single trivial class needs them.  I
> don't see that they need to be virtual either.
> 
> 
>     /**
>      * Function Format
>      * serializes this object out as text into the given OUTPUTFORMATTER.
>      */
>     void Format( OUTPUTFORMATTER* out, int nestLevel ) const throw(
> IOError );
> 
>     /**
>      * Function Parse
>      * fills this object from information in the input stream \a aSpec,
> which
>      * is a DSNLEXER. The entire textual element spec is <br>
>      * (field (name _yourfieldname_)(value _yourvalue_) visible)) <br>
>      * The presence of value is optional, the presence of visible is
> optional.
>      * When this function is called, the input token stream given by \a
> aSpec
>      * is assumed to be positioned at the '^' in the following example,
> i.e. just after the
>      * identifying keyword and before the content specifying stuff.<br>
>      * (field ^ (....) )
>      *
>      * @param aSpec is the input token stream of keywords and symbols.
>      */
>     void Parse( DSNLEXER* aSpec ) throw( IOError );
> 
> 
> Notes: 
> 
> 1) These functions are complementary and are essentially the reverse of
> each other, and a way to round trip an object's contents to text, i.e.
> serialize.  You could envision some unit testing which used this concept
> to verify round tripping integrity if you also had an equality
> operator==() to test an originating.Format() against a receiving.Parse()
> object.
> 
> 2) No UI or error handling is involved within these.  They simply throw
> an exception and *leave UI policy* to the caller.  The DSNLEXER gives
> precise line number and character offsets in its exception objects.
> 
> 3) Clipboard support is easy from here, because you can use a
> STRINGFORMATTER with the Format() function, and you can use
> STRING_LINE_READER with the Parse() function.  So going back and forth
> to memory resident text is easy.  This text can go on the clipboard and
> be passed to your text editor for inspection or modification through
> clipboard operations.
> 
> 4) You have to guard against an exception being thrown from Parse()
> because that will leave an incompletely filled object which needs to be
> destroyed.  You can parse an object on the stack or put a pointer to it
> in a place other than on the stack.
> 
> 5) this is good stuff, and if it is not already clear, it soon will be.

Thanks for the input.  Judging from what I've seen in your DSN and
specctra code, I actually think implementing the new file format will be
the easier part of my changes.  I was referring to some improvements I
would like to make to simplify the component libraries and objects
themselves to support some of the ideas I have for the new file format.
 It is primarily completing the object improvements I started so that
adding new capabilities is not such a chore (think encapsulation here).
 I don't want to get into a discussion about it right now because I
don't have the time to thoroughly discuss it and it is off the topic of
this thread.  I will start a new thread of discussion about it next week
when I have time to work out the details.

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
>