On Jun 15, 9:19 pm, "Gregory Brown" <gregory.t.br... / gmail.com> wrote:
> On 6/15/07, Robert Dober <robert.do... / gmail.com> wrote:
>
> > On 6/15/07, Gregory Brown <gregory.t.br... / gmail.com> wrote:
> > > On 6/15/07, Robert Dober <robert.do... / gmail.com> wrote:
>
> > > > Hmm control maybe, you are not forcing anybody to call
> > > > f.extend(Container) in your approach.
>
> > > Then just pass the constant into the constructor :)
>
> > Huh.. that is exactly what I have suggested, right?
> > I asked why #to_module .
>
> Right.  I was basically saying you don't need to_module because if you
> wanted to force your object to use some container module, you could
> just pass it in.
>
> The .to_module code is gaining you a few chars at most, and I'm not
> sure it's worth it for the lack of clarity it introduces.

#to_module is just a convenience so one can pass in a container module
or a hash (or anything else that responds to #to_module). It's
basically the same as when you accept a string but go ahead and
generalize it to accept anything that responds to #to_s. In other
words, it's a better approach than

  def initialize(settings)
    case settings
    when Module
      ...
    when Hash
      ...

T.