From: Michael Greenberg
Subject: Beware of print-object methods when debugging
Date: 
Message-ID: <mlg.711741357@volvo>
A coworker came into my office this morning to ask for help debugging
his program.  The bug seemed to be in a part of the program that did
processing nodes in a graph. The code seemed to work correctly for all
objects (about 1000 of them) except for one.

Somewhere in the code there was a statement like:

(setf (node-a node) (make-instance 'foo ...))

We would do something like

(dolist (node (all-objects-in-tree))
  (print (node-a node)))

and see the expected results except for one object where 'NIL' was
printed.   The code was pretty complex and there were all sorts of
dependencies between the various objects in the system, so it wasn't
surprising that that was an error somewhere.  

I beat on this for a while trying to figure out what was
going on.  30 minutes later he said "By the way, I also have a
question about print-object...".

It turns out the problem was that his print-object method for the
class 'foo' sometimes printed 'NIL'.



--
Michael Greenberg                      email: ··········@siemens.com
Siemens Corporate Research             phone: 609-734-3347
755 College Road East
Princeton, NJ 08540

From: Gregor Kiczales
Subject: Re: Beware of print-object methods when debugging
Date: 
Message-ID: <GREGOR.92Jul21211018@tracer-bullet.parc.xerox.com>
Yes, this is one of many ways to lose with print-object methods.  I
sometimes think it would be nice if implementations provided some sort
of switch, whereby you could disable the call to PRINT-OBJECT or
something.  Of course, you can do this on an application specific basis,
by writing all your methods in the form:

(defmethod print-object ((o foo) str)
  (if *use-default-printer*
      (call-next-method)
      (print-unreadable... )))

In fact, in an application we have here, I have set it up so that, when
running on a particular kind of machine, something very much like this
is controlled by whether the mode lock key is held down.

Gregor
From: Barry Margolin
Subject: Re: Beware of print-object methods when debugging
Date: 
Message-ID: <14k1ijINNmk@early-bird.think.com>
In article <·············@volvo> ···@siemens.com. (Michael Greenberg) writes:
>It turns out the problem was that his print-object method for the
>class 'foo' sometimes printed 'NIL'.

Hmm, perhaps there should be a global *PRINT-OBJECTS* variable that governs
whether PRINT-OBJECT is called.  It should default to T, but if it were NIL
then the standard #<...> notation would be used for CLOS objects.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

······@think.com          {uunet,harvard}!think!barmar