kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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

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.


Dick