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

Jonas Pfenniger zimba.tm at gmail.com
Thu Jun 8 18:04:55 EDT 2006

On 08/06/06, TRANS <transfire at gmail.com> wrote:
> Looking at this code.... well, lets start here: Is this really
> supposed to define the same method three times in a row?
>       # to_edit_href
>       # ex: admin/articles/edit/23
>       define_instance_method klass, :to_admin_href, %{
>         "\#{AdminController.mount_path}/\#{self.class.name.underscore.pluralize}/edit/\#{oid}"
>       }
>       if defined? AdminController
>         # to_admin_href
>         # ex: admin/articles/list
>         define_instance_method klass, :to_admin_href, %{
>           "\#{AdminController.mount_path}/\#{self.class.name.underscore.pluralize}/list"
>         }
>         # to_admin_href
>         # ex: admin/articles/list
>         define_class_method klass, :to_admin_href, %{
>           "\#{AdminController.mount_path}/\#{self.name.underscore.pluralize}/list"
>         }

Some parts are only well understood by George I think.

> > Otherwise, look in "nitro/lib/nitro/controller.rb". There is a mess
> > with the Publishable module I don't even want to understand.
> Is that module being used at all? Is there something preventing it
> from using class_inherit?

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.

> I just want to make sure all you Glyceriders... I mean the NCT ;) knows that
>   def self.included( base )
>     base.module_eval { ... }
>   end
> is a NO NO. It misrepresents what's really going on. The class
> hierachy will show the module included, but in actually the code has
> been pasted directly into the class --their is no inheritance, you
> couldn't redefine a method and call super from it, etc. Moreover the
> class methods one might define in this way, to get around the lack of
> class-level module inheritance, are only effective at one level, a
> module of this kind included in another module will not be effective.
> So please do not use this technique and help root out all occurances
> of it. I spent a good bit of time myself getting rid of it in Og about
> a year ago.

This is an interesting point I've never thought of, thx for the
clarification :-)

> 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.

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 ?



More information about the Nitro-general mailing list