"Simon Strandgaard" <neoneye / adslhome.dk> schrieb im Newsbeitrag
news:pan.2004.02.25.14.22.29.534174 / adslhome.dk...
> On Wed, 25 Feb 2004 15:09:03 +0100, Robert Klemme wrote:
>
> >
> > "Simon Strandgaard" <neoneye / adslhome.dk> schrieb im Newsbeitrag
> > news:pan.2004.02.25.13.47.23.98604 / adslhome.dk...
> >> On Wed, 25 Feb 2004 14:26:36 +0100, Robert Klemme wrote:
> >> > "Simon Strandgaard" <neoneye / adslhome.dk> schrieb im Newsbeitrag
> >> >> Its syntax is
> >> >>
> >> >>     debug :method [, :method]*
> >> >>
> >> >> What it does is to enable the global flag $debug.
> >> >
> >> > More precisely it switches all output on or off in a method.  And
> > that's
> >> > what I don't like about it: in your example class A behavior of
> > "puts",
> >> > "print" etc. changes depending on the $debug flag.  That's IMHO not
> >> > compliant with POLS.
> >>
> >> Agree it isn't POLS, but debugging is sometimes tuff.
> >
> > Taff?  Well, yes it is.
>
> First I tried with 'toff' but it looked wrong ;-)

Actually, "tough" looks even better. :-))

> >> I never remove print statements.. because I one day might need that
> >> information. Then a debug keyword + Debuggable module is practical.
> >> I have attached a debug output from a testcase (my regexp project).
> >>
> >> I have used logfiles in the past.. but in conjunction with
> >> unittesting they seems to be not needed.
> >>
> >>
> >> > I'd prefer to have specialized methods for debug printing.
> >> >
> >>
> >> Please enlighten me.  How do you debug ?
> >
> > ?  Sorry if I wasn't clear enough.  The thing I don't like is the
naming
> > of the methods used for debug printing.  I mean, rather use different
> > names than "puts", "print" etc. in order to be able to have regular
output
> > as well as debug output.  Also it helps in identifying lines that can
be
> > taken out once the code is ok.  (Ok, you don't take them out so this
> > argument doesn't count for you - but other IMHO.)
>
> Understandable.. using puts, print has drawbacks.  Good suggestion, I
> think I will replace them with something else.
>
> Any ideas for a good name?
>
> debug replacement puts  ->  #debug_puts,  #dputs
> debug replacement p     ->  #debug_p,     #dp

Hm...  I'd go for "d_puts" which is immediately distinguished from "puts"
but is not so much typing overhead as the more verbose "debug_puts".

> maybe just turn the 'p' in 'puts' upsidedown, so it becomes a 'd' =>
duts?

http://www.best-lyrics-zone.net/Upside_Down_Lyrics.html
:-)

> > Is there a reason why your debug output methods need to override
methods
> > defined in Kernel?
> >
>
> do you mean 'class Module'?

Nope, that question was referring to the naming of the methods which in
turn lead to shadowing the original methods "puts" etc. (see above).  But
I think we have sorted that out by now. :-)

> Yes there is a good reason.. by having it here, allows me to use
> the debug keyword inside modules. Like this:

Of course.

<snip>

> >> It would be nice to identify a good model for advanced debugging with
> >> Test::Unit.
> >
> > Yeah.
> >
>
> Agree ;-)

You agree to yourself?  That's a good sign - at least you don't seem to
suffer from MPD* (at leat not at the moment. :-))

Cheers

    robert


* http://www.multiple-personality.com/