[ET Trac] [Einstein Toolkit] #221: Simfactory should complain about unused arguments

[Einstein Toolkit]

#221: Simfactory should complain about unused arguments
-------------------------+--------------------------------------------------
  Reporter:  eschnett    |       Owner:  mthomas 
      Type:  defect      |      Status:  reopened
  Priority:  major       |   Milestone:          
 Component:  SimFactory  |     Version:          
Resolution:              |    Keywords:          
-------------------------+--------------------------------------------------

Comment (by eschnett):

 Simfactory contains already code to distinguish between global options
 (valid for all commands) and "local" options (valid only for certain
 subsystems). Unfortunately, this distinction turns out to be inconvenient;
 for example, --parfile is defined in the "simulation management"
 subsystem, but this means it is valid for both "create" (good) and
 "submit" (unused). We should modify this scheme to have options not for
 subsystems, but for individual commands instead.

 At the same time, we could also define options in the source code (near
 the commands) instead of in separate .ini files. I don't see a benefit in
 having these .ini files separately. The options for a command could be
 defined in a hash table with name similar to the command, so that the
 respective option table can be found automatically when a command is seen.
 Or commands could be implemented in classes, and the class could a method
 returning the valid options.

 I dislike a distinction between "sim --verbose submit" and "sim submit
 --verbose". If we reject the second, then we should should accompany it by
 an error message "please say 'sim --verbose submit' instead", and this
 seems a bit silly, since we may just interpret it this way in this case.
 Distinguishing between before-command and after-command options makes only
 sense if there are a lot of commands that have been designed
 independently, such that there are options that have different meanings
 depending on whether they come before or after the command (e.g. "cvs -d"
 comes to mind). I'd rather have a small set of options that is designed
 coherently (even if this requires lengthy discussions on the mailing
 list).

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/221#comment:8>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit