2011/1/10 Bernard Lambeau <blambeau / gmail.com>:
> Hi!
>
> * #options could return the OptionParser object, so as to allow
>> #options.on directly.
>>
>
> Well, I want options to be installed on a class basis while being parsed by
> a command *instance*. This is the only hack I've imagined so far. I would be
> interested in any alternative one could propose that fit this double
> constraint. Any idea?

Yeah I get it. Still, you could store those blocks somewhere, and
apply them when on the OptionParser instance later-on. Would that do
the trick ?

>> * how is the delegator -> subcommand relation made ? it's maybe best
>> if it's explicit.
>>
> The relation is made through introspection of ruby namespacing (a delegate
> simple command is a class defined under a delegator namespacing). I could
> indeed propose additional features to override this proposed behavior.

Yeah, that's what I thought :) A bit too magic for me, but it's just a
matter of taste.

>> * if a delegator has a global option like --verbose, is @verbose =
>> true going to be set in the subcommand ?
>
> Not directly. But subcommands have access to a requester object (via an
> attr_reader), which is the delegator in such a configuration. You can access
> delegator.verbose. I'm still investigating the question so far...

I see, makes sense to me. Maybe if you store the options-parser blocks
like I said before, you can inherit them too, not sure if that makes
sense though.

> Thanks for your feedback!
> B

Cheers !
  zimbatm