On Thursday, November 23, 2017 at 1:40:25 AM UTC-6, Edward K. Ream wrote:
So we have a dilemma. One the one hand, it's *always* better to use
> classes to encapsulate related functions. Otoh, it would be intolerable
> for text transformations to introduce subtle bugs in commander commands.
> Existing unit tests don't cover all the cases. I'll have to think about
> this...
>
Emacs never suffered from this dilemma because elisp had (then) no classes
:-) All Emacs "macros" exist in a global namespace.
Rather than risk having to change the sources for commander commands, we
could just use functions that "masquerade" as methods. Like this, at the
top-level of commanderFileCommands.py:
@g.commander_command('save')
def save(self, event=None, fileName=None):
# Exactly the same code as before.
Notes:
1. @c.command won't work, because c doesn't exist at the top level. And it
probably wouldn't work within a class either. So we will probably want to
define the @g.commander_command decorator. It should be no big deal.
2. Pylint might complain about functions having a "self" arg. All such
complaints can be disabled at the start of the file.
3. I'm not sure what pyflakes will do. *This could be a show stopper* for
using functions. I'll check this immediately.
*Summary*
The dilemma isn't resolved. It may, after all, be preferable to use new
subcommander Classes, even if some text munging is required.
In any case, @c.command will likely morph into @g.commander_command.
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.
