Cmd Todo list

Send suggestions for this list to marcel@vernix.org.

Todo list

• The subclassing from Cmd and defining do_ methods for commands paradigm is a bit limiting. So, ideas for radical change:

  Cmd is a module. All do_ methods are no longer the way to write commands. There are two ways to get Cmd functionality into a class.

  1) You mix in Cmd::Interpreter (or something like that). You then just define methods in the class where Cmd::Interpreter is mixed in, and then use a command macro to indicate that the method is a command.

  e.g. 
    command :add
    def add(etc)

  This would be useful fo pre-existing classes that would like to add Cmd behavior. [credit Chad Fowler and Sam Stephenson]

  2) There is a Cmd::Base class that mixes in Cmd::Interpreter. You inherit from Cmd::Base and in this case all methods that are public are commands implicitly without needing to use the command macro. This base class would be a convenience class that automatically defnotes every public method as a command method.

• Cmd::ClassMethods sucks. Using the singleton vars sucks. Create a metaprogramming framework that is self hosting. It would be used to create the domain language that would describe domain languages. [credit Sam Stephenson]

• Create a way to define named-parameter options hashes and define certain options as depending on other options. The allowed parameters should be able to be changed depending on the values of a certain parameter. [credit Sam Stephenson]

• Writing a complete_(command name) is enough to have the completion results be displayed, but not enough to actually complete. In order to complete as well there must be additional logic such as what complete_grep does. So right now to do a completion method for a command you really have to do something like:

  def complete_find(line)
    completion_grep(@numbers.keys.sort, line)
  end

  Where the first argument is the collection to complete against and line is what is passed in. This API should be simplified and it should have a better name than completion_grep. Also the subclass has to remember that the complete method has to take an argument. It would be better to not have them have to do that. Perhaps introduce (another macro) class method that just takes a collection, or a method reference that returns a collection that then is operated on internally.

  complete :find, :with => :phonebook_names
  
  # ...
  
  def phonebook_names
    @nubers.keys.sort
  end

  or

  complete :some_command, :some_other_command, :with => { # Some Proc }

• Add a Documentation class (or some such) which collects list of subcommands and shortcuts so that the default help command can be more helpful and complete.

• Make it so that doc allows one to document arguments for commands that take arguments so that rather than just:

  add  -- Add a number into the phonebook.

  You'd get something more like

  add name number [phone type]  -- Add a number into the phonebook.

• Have doc work like the 'desc' method for rake where it preceeds the task to which it describes rather than specifying the task excplicitly as args.

• Get rid of do_ method naming convention and define a 'command' method to replace the naming convention.

  def do_subtract
    # ...
  end

  would become

  command subtract do
    # ...
  end

  How to deal with method arguments? Perhaps doing:

  command subtract do |arg|
    # ...
  end

  Sam suggests command being the death of the doc macro:

  command :add, 'Add an entry' do |name, number|
    @numbers[name.strip] = number
  end

  I think that's pretty nice.

  UPDATE: The above todo regarding making Cmd a module and having the choice of subclassing Cmd::Base or mixing in something like Cmd::Interpreter obsoletes this approach.

• Take another shot at having more objects (e.g. Command, Subcommand, Documentation, etc)

• Provide a means of documenting subcommands

• When passing arguments to do_ methods do a better job of just checking if the method takes arguments and then passing them all in with *args. Do all the arity checks and then pass it as many args as the do_ method takes. Raise some client catchable exception if nothing can be done with the passed args to satisfy the method signature of the do_ method. Basically make the do_ command methods as much like ruby methods as possible so that the arguments are handed to the command so that it can access them directly rather than having to fish them out.

  So get rid of tokenize_args...it's a busted idea. Instead have

  e.g.
  
    def do_add(name, number)
      # ...
    end

  If the method that takes care of passing a command the appropriate number of arguments can't do its job based on the input given then the default could be something like announcing that there was an argument error (perhaps formalized using handle) and then the help for that command should be displayed.

• Implement rudimentary interaction with the underlying shell using the standard | pipe notation and > redirection notation so that someone could do:

  prompt> command | sort
  
  or
  
  prompt> command > commands-output.txt
  
  and maybe
  
  prompt> command | sort > sorted-command-output.txt

  Though I don't really want to write anything too fancy or complicated. I think the most basic functionality of pipes and redirects would be useful though.

• Perhaps allow subclasses to override the tab as the completion key.

[Validate]

Generated with the Darkfish Rdoc Generator 2.