From: Rick DeNatale <rick.denatale@...>
Date: 2007-09-08T07:14:42+09:00
Subject: Re: before, after and around Ruby 1.9

Just to try to crystalize my own thoughts about this in general. I'm
concerned that because of the dynamic nature of "assembling" the
pieces of a Ruby program, some of these proposals might lead to
indeterminate  (or at best mysterious) results because of the
difficulties in figuring out the order of code parsing/execution.  For
example, Rails loves to automatically load code 'on demand' using
Module#constant_missing  this leads to subtleties in 'sophisticated'
Rails coding such as using


   Foo.class_eval do
       #class modifications here
   end

instead of the more usual

  class Foo
     #class modifications here
  end

In the case where the Foo being 'opened' doesn't actually exist yet,
the more normal code will create it, and the modifications will at
best be overwritten when the 'real' class definition is encountered,
and at worst the 'real' class definition won't be loaded at all
leaving a class with rather anemic capabilities.

In Rails, due to its use of constant_missing, the first form will
actully load the original class and then modify it.  Not that this is
necessarily, and it probably isn't without thinking about it too much,
a good thing to add to the base language.

In a related vein, Charlie Savage recently wrote a thoughtful analysis
of one of the ways which Rails uses alias_method to do 'poor mans'
aspect oriented programming to implement the GOF decorator pattern

http://cfis.savagexi.com/articles/2007/09/05/rails-unusual-architecture

He makes some points about why this might not be the best approach.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/