On 6/15/07, Trans <transfire / gmail.com> wrote:
>
>
> 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.

I understand what it's for, I just don't think it's very useful.