Re: A few questions on PCL

[Gregor.pa@Xerox.COM]

    Date: Fri, 09 Dec 88 15:13:29 -0500
    From: Mike Thome <mthome@VAX.BBN.COM>

    I've got a few questions for the "community" relating to pcl:

    1) Cache mechanism - although I haven't yet looked at this part of the
    new version, I assume the new cache method ("mirror" lookup for 2nd
    chance before slowing WAY down) is used.  How does this method
    differ (in efficiency) from the fairly standard "try the next cache
    location" algorithm in normal hash table theory?

Its hard to tell.  There are some conjectures that the mirror location
is better because the next location might be occupied by the class that
was created immediately after the current class.

Computing the mirror probably doesn't take any longer, so in secondary
hit case, this scheme is just as fast.

It is easy to write a tool that takes a snapshot of a running program
and statically compares these two techniques.  I wrote such a hacked up
tool and it suggested that the mirror was slightly better than the next.
I certainly wouldn't want to make that as a justified claim without
making more careful measurements with a large program base.  For one
thing, a lot of it depends on how the class numbers are generated.

    2) Defmethod currently returns the method object of the method it just
    defined. Why doesn't it return the method's name (i.e. "(method foo (t))"
    my reasoning is to be like defun).

Two reasons, one important and one very important.

  - important, this is what the spec says

  - very important, methods don't have names.  Generic functions have
    names.  We worked real hard in CLOS to try to separate names from
    the actual program objects.  One step in that is to eliminate
    gratuitous names, like names for methods.
 
    3) In an optimal PCL debugging environment, how much of the internals of
    pcl should be invisible to a baktrace?  Should call-next-method appear?
    What about combined method objects or the generic function call itself?

I personally expect there will be a lot of interesting design here.  I
would think that call-next-method should definitely be visible.  I would
think the generic function call should be visible.  Probably something
to indicate the effective method should be visible as well.

Of course all of these should be handled better than they are in most
PCL ports.  Stan Lanning's PCL port to Envos Medley handles all of these
pretty well.  It displays the actual generic function and method objects
on the stack.  This is another example of the kind of thing you need to
do if you want to attain a clean separation between names and program
objects.  The advantage to Stan's scheme is that if you have an anymous
generic function and some methods on it, and you wind up in the
debugger, the debugger handles them gracefully.
-------