On 10/7/2010 5:02 PM, Dick Hollenbeck wrote: > On 10/07/2010 01:59 PM, Wayne Stambaugh wrote: >> I'm getting ready to do some refactoring of the library object code and I >> would >> like to split the component library object file classes_body_items.cpp into >> individual files per object. This file is currently over 2000 lines long and >> has become unwieldy to edit. One thing I'm not particularly thrill about is >> the current class_foo.cpp file naming scheme. It seems redundant to me >> prefix >> class_ to C++ source files. Would any one object to them not be prefixed >> with >> class_. In other words lib_arc.cpp, lib_circle.cpp, lib_rectangle.cpp, etc. >> I >> would like to get this complete before we create the branch for the new >> library >> stuff to prevent merge issues. There is no formal policy on this so I >> thought >> I would ask before I plow ahead. >> >> Wayne >> > > I thought that was something dear to Jean Pierre. For me the version > control system support for renaming is a factor. bzr says it handles > it. Mostly I don't care, because for the work I would do in a separate > branch, I would not even start with any existing files.
I think you are correct about JP liking the class prefix. In fact I may have been the one to ask this before. It's hell getting old. The memory is the first thing to go. > > > They would be hand copied over one by one over but only if I needed > them. That branch might never make it to fully functional eeschema, > just the lower level stuff only. Then we'd have to park the GUI stuff > on top of it, but until then I would not even want GUI stuff in the same > directory, so that dependencies on the GUI do not crop in too early. > > This is an entire foundational restart in terms of the underlying datatrees. > > Once that is in place, then the GUI stuff is where most of the > re-usability would come into play, and more files could come over, or we > could bring the new files into the existing tree. > > It sounds good, untangling it is another thing, and it may be harder > than it sounds. This effectively means the new branch becomes EESchema as there would be no way to merge it back into the testing branch without hand copying it back over. That could prove just as difficult as copying the UI parts into tne new tree. I'm not sure this it the way to go. I'll sleep on it. Maybe I can see way more clearly tomorrow. Wayne > > > > _______________________________________________ > 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
