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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
