On Oct 7, 10:42 am, "Pat Maddox" <perg... / gmail.com> wrote:
> On 10/7/07, Trans <transf... / gmail.com> wrote:
>
>
>
>
>
> > On Oct 7, 9:13 am, "Pat Maddox" <perg... / gmail.com> wrote:
> > > On 10/7/07, Austin Ziegler <halosta... / gmail.com> wrote:
>
> > > > On 10/6/07, Trans <transf... / gmail.com> wrote:
> > > > > The thing is (and maybe this will help clarify how I see this) the
> > > > > more I work with Ruby the more I feel like the best code is always of
> > > > > the form:
>
> > > > >   module M; end
> > > > >   module X; end
> > > > >   module Y; end
>
> > > > >   class Z
> > > > >     extend M
> > > > >     include X
> > > > >     include Y
> > > > >   end
>
> > > > > Such that everything is a module and classes are always just
> > > > > compositions of modules. This provides maximum code reusability.
>
> > > > I'll put it clearly: if I were running a Ruby consultancy and a
> > > > programmer of mine used your methodology for everything (e.g., classes
> > > > defined by composing modules), I would not keep that programmer on. It's
> > > > a bad style. Sorry.
>
> > > Agreed.  That looks painful.
>
> > Bahahahahahahahahaha!
>
> > You're right! But it's only painful b/c it's what you HAVE to do today
> > to achieve this level of code reuse. If I had my way, it would as
> > simple as:
>
> >   class X
> >     def self.foo  # instead of needing M
> >     ...
> >   end
>
> >   class Y; end
>
> >   class Z
> >     is X
> >     is Y
> >   end
>
> > And we'd still have complete code reuse.
>
> > T.
>
> You misunderstand me.  What looks painful to me is having the behavior
> of a class tucked away behind 15 different modules, instead of being
> right in the class where it belongs.

I see. Well it's a trade-off. Would you prefer a class with 50
attributes or one that divides those into a few groups based on what
they concern? For instance I have a Package class, it consists of
General, Version, Content and Control components. I use that as a
library reference object. However when I want to use it for creating
distributable packages I mixin Distribution and Dependency modules.

T.