From: "ara.t.howard" <ara.t.howard@...>
Date: 2008-06-24T01:06:35+09:00
Subject: Re: Is it ellegant to use a global variable to store a Logger   object?


On Jun 23, 2008, at 9:10 AM, Suraj Kurapati wrote:

> Not really.  You can refactor that bit of meta programming into its  
> own
> module:
>
>  module AddLoggingToNested
>    def self.included target
>      # ... code from previous e-mail ...
>
>      extender[target]
>    end
>  end
>
> Now, you can add this propagation of logging functionality to any
> top-level module or class by simply doing:
>
>  module MyProjectTopLevel
>    # ...
>
>    include AddLoggingToNested
>  end
>
> Note that the include musts be done *after* all nested classes have  
> been
> defined.  That is why I put that include() statement at the bottom of
> the module's code.


this is a bad idea.  try to use rails' code with other code that uses  
ruby's logging class and you'll see what i mean.  it's better just to  
keep things simple imho - your meta-programming bit will fail, for  
example, if someone does

module M
   extend AddLoggingToNested
end

i agree with robert that logging is (typically) a global task and thus  
the interface should reflect that.  i'd use something like

module Namespace

   module Logger
     Instance = ::Logger.new STDERR

     %w( debug info warn error fatal ).each do |m|
       module_eval <<-code
         def #{ m }(*a, &b)
           Instance.#{ m }(*a, &b)
         end
         def self.#{ m }(*a, &b)
           Instance.#{ m }(*a, &b)
          end
       code
      end
   end

end

which does three things

  - box your methods in a namespace

  - allow access via: Logger.info ....

  - allow access via: include Logger, info ...

perhaps it might make sense to auto-mixin, but tha'ts a layer on top  
of this.

kind regards.


a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama