On 4/13/07, Tim Pease <tim.pease / gmail.com> wrote:
> On 4/13/07, Robert Dober <robert.dober / gmail.com> wrote:
> > Hi list
> >
> > this is incredibly simple, but I just wanted to know what you think about it.
> >
> > I really often write the following code
> >
> > puts <whatever> if $DEBUG
> >
> > I guess you all do that to some extent, James just talked a newbie
> > into it recently ;)
> >
> > The first programmer's virtue of course makes me do some things like
> > def debug *args, &blk
> >    return unless $DEBUG
> >   <do something incredibly smart with the args ;)>
> > end
> > and sometimes on some of my machines I will do something like
> >
> > require 'ilmig/tools/debug'
> >
> > I feel that this might be so common place that a Kernel::debug or
> > whatever other suitable name might be a good idea.
> >
> > I am listening .... ;)
> >
>
> For medium to large programs having a global $DEBUG flag is going to
> create lots of "line noise" as all those debug messages go whipping
> by.
Tim the $DEBUG mechanism is quite primitive and other things are
needed for large scale development, no doubt.
My idea of the CR is orbiting around $DEBUG which is widely used  in
quick hacks or small to medium scale development, but...
>
> I much prefer the fine grained control that the 'logging' and 'log4r'
> packages give you.
>
>
> require 'logging'
>
> class A
>   def initialize
>     @log = Logging::Logger[self]
>     @log.debug "new object created '#{self.object_id}'"
>   end
> end
>
> class B
>   def initialize
>     @log = Logging::Logger[self]
>     @log.debug "new object created '#{self.object_id}'"
>   end
> end
>
> Logging::Logger['A'].level = :warn
> Logging::Logger['B'].level = :debug
>
>
> It's a little more setup, but you have far greater control over what
> gets logged and what doesn't. The framework also takes care of
> timestamps, outputting class info, etc.
>
> And if you don't want all that complexity, there is always the core
> Logger class that comes with Ruby.
>
> Blessings,
> TwP
... I take one idea from your mail, with your kind permission ;)

Why not enhancing the semantics of $DEBUG at the same moment, I will elaborate
-----------------------------------------------------------------------------------
def Kernel.debug *args, &blk
   return unless $DEBUG
   begin
      $DEBUG.puts args.join(" ") unless args.empty?
      blk.call $DEBUG if blk
   rescue
      warn $DEBUG does not respond to the #puts message
   end
end

now you can write code like

debug "OMG this should be deadcode, why I am here, I just kept that
code for sentimental reasons!!!!"

or
debug do
   puts "whatever"
end

or

debug {
   | stream |
   stream.puts "@inst = #{@inst}"
}

or
debug do
  $DEBUG.print "one"
end

of course the -d switch of ruby would just set $DEBUG to $stdout,
maybe a -l <stream>
switch could be introduced to set $DEBUG to a writeable IO object
representing <stream>
------------------------------------------------------------------------------------------------------

Now I realize I did not think about other debugging mechanisms, the
core idea is just to simplify what I think is a common and useful
idiom namely
  puts "/...." if $DEBUG

I do not think that this will compete with more advanced debugging,
logging features, but why not enhance the $DEBUG switch as suggested
above.

Yeah and before I forget, thx for your input Tim.

Cheers
Robert

-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw