On Fri, Nov 24, 2017 at 12:29 PM, Terry Brown <[email protected]> wrote:
Just want to check I understand this project. > I've been playing with the project all day, trying to understand every little nuance. I believe the latest revs are just about perfect. > Starting afresh, No, the project does not start afresh in any sense. There are no new classes, no new subcommanders. From a "live" objects point of view, almost nothing whatever has changed! The *only* change to the init code is that c.initObjects must import the commander* modules so that decorators will be executed. The *only* potential problem is that some of c's methods have become hidden helpers. Mostly that's *good* (it cleans up c's namespace), but there is a slight possibility that some script might use one of these helpers. If so, it will be easy to restore them. See below. The @g.commander_command decorator is the key to everything. In essence, it allows commander methods to be defined outside of leoCommands.py. That's the *only* real difference in the code! So the project is *only* about clever packaging. The "proof" of this is that only simple changes have been made to the actual code. Helpers typically are no longer c methods, so their signature change to have a c arg instead of a self arg. The assignments c = self go away in these helpers. As I have gone along, it has become clear which helpers should be hidden. These are just the helpers used internally by some command or other. It's unlikely that outside code will ever know or care about these helpers. It would be no big deal if they need to become c methods again. Just: - Move them back inside the Commands class. - Change the signature to use self instead of c. - Restore the assignment c = self. - Have the calling code call c.x(...) instead of x(c, ...). Almost all methods that define commands have migrated to the various commander*.py files. Yes, there is some magic involved in injecting the functions into c, but the @g.commander_command decorator marks this magic explicitly. All the *remaining* methods of the Commands class are either part of c's fundamental api, or are useful helpers. This wasn't apparent to me this morning. I have spent several hours today organizing c's methods. The present categories are much much clearer than before. Have a look at the organization of the Commands class! Crucially, none of this reorganization affect the methods themselves in any way. It only affects our understanding of the class. > Just making sure I understand this very large change. Happily, the project is a *small *change to Leo's code. Pyflakes, pylint and unit tests have caught all problems quickly. I have been eating my own dog food without any problems whatever. I expect only minor problems after the cmds branch merges into master. Please feel free to ask more question. I don't plan any major changes to the code. I am fairly shocked by how easy all this has been. 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
