This branch contains a thorough refactoring of the top-level atFile output code. It removes most kwargs, a major simplification. Please report any problems immediately.
Yesterday's post <https://groups.google.com/d/msg/leo-editor/JfAUMMOSdvQ/HmbHXmm3EAAJ> suggested a refactoring strategy. The actual refactoring, however, took a completely different course. The rest of this post provides details. Feel free to ignore. The highlights: 1. Four new methods write to strings: at.getAsis, at.getAtAuto, at.getAtEdit and at.getFile. These are top-level methods, so they do all necessary inits. Writing these methods first was a happy accident. As I was writing them, I realized that using these specialized methods collapsed the complexity of the init code. Not just in these methods, but in the *already existing* methods. This was Vitalije's idea. It was only when I saw the collapse actually happen that I understood how much complexity the various kwargs introduced. 2. Thereafter, I spent five or six hours eliminating the 'toString' and 'force' kwargs from the atFile write code. This had to be done carefully, in tiny steps. Happily, existing unit tests caught all problems. I removed the test for 'toString' from at.openFileForWriting by creating a new at.openStringForWriting method. Besides the new at.getX methods mentioned above, this was the only "method splitting" needed. 3. There was no need for any code "diagrams". cff made everything clear. 4. I had been concerned that lots of code would have to be duplicated. But this was never a problem. The only exception was the complex code that writes @auto files. This was initially duplicated in at.getAtAuto and at.writeOneAtAutoNode. A new helper, at.writeAtAutoContents, eliminates the shared code. It's no big deal. 5. The code that writes to files (as opposed to strings) does *not *use string-based code. The two code bases are completely separate. It's surprising, but the existing code seems like the simplest thing that could possibly work. *Summary* The new refactoring has been a great success. It proceeded methodically. Unit tests check the work. A few kwargs remain. The most important are the 'sentinels' or 'nosentinels' kwargs. These set the at.sentinels ivar, for use by the code that actually writes the contents of files. I see no reason to eliminate the at.sentinels ivar. Doing so would be a dangerous, and would not clarify the top-level code in any way. For now, this project appears to be complete. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
