SuperCommand now just handles subcommand selection

SuperCommand now just handles subcommand selection

...and LoggingSuperCommand embeds it, and adds logging flags, as before.

https://code.launchpad.net/~fwereade/juju/go-split-supercommand/+merge/103065

Requires: https://code.launchpad.net/~fwereade/juju/go-recurse-parse-directly/+merge/103064

(do not edit description out of merge proposal)

[fwereade, 2012-04-23 09:26:07]

Please take a look.

[niemeyer, 2012-04-23 23:25:43]

https://codereview.appspot.com/6100050/diff/1/cmd/supercommand.go
File cmd/supercommand.go (right):

https://codereview.appspot.com/6100050/diff/1/cmd/supercommand.go#newcode12
cmd/supercommand.go:12: // again on itself, passing in any remaining command
line arguments. Info,
It feels like we misunderstood each other. The behavior that is still documented
and implemented here is what I suggested should be changed and you apparently
agreed (but I probably wasn't clear):

Apr 19 10:04:38 <niemeyer>      fwereade_: I think a new type that handles the
part of the problem of a supercommand preparing a subcommand to might actually
simplify things 
Apr 19 10:04:42 <niemeyer>      fwereade_: and make that logic more readalbe
Apr 19 10:05:09 <fwereade_>     niemeyer, awesome; then I'll try that direction
Apr 19 10:05:23 <niemeyer>      fwereade_: It feels clever, and "saves a type"
(?), but at the same time this isn't the first "Wait, what?"    moment we reach
with that logic
Apr 19 10:05:30 <fwereade_>     niemeyer, I was worried you might see it as
wanton code raviolation
Apr 19 10:05:37 <niemeyer>      fwereade_: It may be time to at least check how
that'd look like
Apr 19 10:06:13 <niemeyer>      fwereade_: I suspect it will be simple by
itself, and will also make the supercommand implementation more      obvious

Instead, you've split out the *logging* which feels like the wrong place to
slice off.

I apologize for being unclear, and for increasing the amount of work going on in
this already overworked topic. If you disagree or still don't understand what
I'm saying, I'm happy to discuss it once more to make sure we're at least in the
same page, even if we don't agree on the solution.

[fwereade, 2012-04-24 08:15:12]

Heh, according to my own definition, splitting off the selection is exactly what
I did.

The choices I can see are:

* original: unified type with a flag to disable logging.
* current: SuperCommand has been "split off" and can now be used on its own (for
cmd/jujuc/server); and it's also embedded in LoggingSuperCommand.
* ravioli: create separate LoggingCommand and SuperCommand; embed them both in
LoggingSuperCommand.

Each of these allows for easy-enough creation of commands that either expose
subcommands with logging flags or just expose subcommands. There's no current
use case for just exposing logging flags, so I dismissed the [ravioli] solution
as overengineering; but I'd be more than happy to do it that way.

Was that your original intent, or have I missed something? Because I don't think
the converse of [current] makes sense: splitting out a separate LoggingCommand
inevitably leads to either [ravioli] or a variant of [original], because we need
selector types both with and without logging flags.

Right..?