New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define all commands using a LeoCommand class #581
Labels
Comments
On Sun, 19 Nov 2017 12:54:07 +0000 (UTC) "Edward K. Ream" ***@***.***> wrote:
Perhaps all command methods should be defined in subclasses of a new
LeoCommand class. This class might be decorated with, say,
***@***.***_class('class name', 'optional_commander_ivar')`
`@command_class('*command name*', 'optional_commander_ivar')`?
The optional arg would inject the class's command method into the
appropriate commanders, This would remove a long-standing hangnail.
The g.command decorator creates most classes, but there are too many
behind-the-scenes complications, including g.cmd_instance_dict. The
LeoCommand class might hide such details. Or not.
Without understanding it better, I'd vote -1 on this. If I read
correctly,
g.command('my-command')
def my_command(event):
event['c'].my_command_handler.do_thing()
becomes
g.command_class('my-command')
class MyCommandClass(LeoCommand):
def command(event):
event['c'].my_command_handler.do_thing()
If the class's only member is command() I can't see a need for the class.
If optional_commander_ivar causes command() to become an instance method
of c.getattr(optional_commander_ivar), well, I guess that could be neat,
but I'm not sure that's what you meant, and still don't see a need for
the class.
|
On Sun, Nov 19, 2017 at 10:48 AM, Terry Brown ***@***.***> wrote:
Without understanding it better, I'd vote -1 on this.
Your comments are well taken. Let me play around with
g.command_class('my-command')
class class MyCommandClass(LeoCommand):
...
to see if there is *any* advantage in this pattern.
Alternatively, perhaps the g.command decorator can be hacked to allow automatic injection of the defined command into the commands class. This is what I really want to do. I am willing to add move behind-the-scenes complications to make it happen.
|
edreamleo
changed the title
Define all commands using a LeoCommand base class
Define all commands using a LeoCommand class?
Nov 21, 2017
I am going to close this issue. It was a bad idea. Furthermore, #589 accomplishes even more, and more simply. |
edreamleo
changed the title
Define all commands using a LeoCommand class?
Define all commands using a LeoCommand class
Dec 4, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Perhaps all command methods should be defined in subclasses of a new LeoCommand class. This class might be decorated with, say,
@command_class('class name', 'optional_commander_ivar')
The optional arg would inject the class's command method into the appropriate commanders, This would remove a long-standing hangnail.
The g.command decorator creates most classes, but there are too many behind-the-scenes complications, including g.cmd_instance_dict. The LeoCommand class might hide such details. Or not.
The text was updated successfully, but these errors were encountered: