[Nitro] Fwd: Troubles along the class-level heirarchy

TRANS transfire at gmail.com
Fri Jun 9 01:12:01 EDT 2006

On 6/8/06, Jonas Pfenniger <zimba.tm at gmail.com> wrote:

> Yes it is used as a way of abstraction because it is then included in
> the Controller. I think it is only there to specify the publishing
> side of it but the contract is not much clearer to me.

Amazing, cause there's two clear bugs in that snip of code.

> > Unfortuantely Ruby doesn't exactly make the proper approach very easy.
> > But in most cases using class_inherit (from Facets) will do the trick
> > --it sets up proper module inheritace through the class level hierachy
> > (and BTW is the successor to the out-dated ClassMethods approach).
> I don't know really. A programming language is just a tool that allows
> you to represent the way you want to solve a specific problem. The
> problem is, that with a too powerful language it also gets harder to
> map the problem in your mind. You spend more and more time trying to
> figure out how to do it in the language instead of just writing
> something. I think "entreprise java" is a good example of this. A
> whole new world is created that generates new problems and in the end
> you have a big pile of code that's just here to make good or follow
> useless standarts.

True enough, but there's also getting to know your lanaguage. And that
generally means working with the code a lot, esspecially trying out
new things and studying other's examples. If you just sit down and
start banging out code in a laguage you barely know you're going to
get a lot of what you're talking about. That's okay, as long as you
coninually refine your style over time. If your stuck in that same
mode of coding though (and I think people do this b/c they "fall in
love" with their own code) then you're pretty much going no where.

> On one side, ruby is a wonderful langage because it allows you to take
> shortcuts where a big pile of adaptor classes would be used in other
> languages. That's what makes it elegant. Modules are exactly there for
> that. Avoid the complexity of multiple class inheritance, but still
> having some flexibility.
> Looking at the Nitro code, I'm often wondering what some bits of code
> are doing. Nitro is maybe using too much magic. By trying to abuse the
> language you're maybe getting something smaller but not necessary
> clearlier. My point is that I fear, but I'm not sure, that the
> percieved problem of Module/Class inheritance is maybe just a smell of
> bad code and that adding yet another way of inclusion would bring more
> complexity. And this maybe why it's so hard to find a real world
> problem where it is necessary ?

Well, class-level "inheritance" is useful as is clear by the fact that
it is used often --no doubt one can divide things into more modules,
that's an option. Then you'd extend and include as neded --but doesn't
it seem silly when it's always both for one hing? Eg.

  include FooIncludable
  extend FooExtendable

No sense it this lack of DRY. And if Nitro did this it would be prerty
full of such.

Nonetheless, you are absolutely right. Nitro is too much *black* magic
under the hood.


More information about the Nitro-general mailing list