Making (CLASS-OF <class>) be EQ to <class>

[Jon L White <jonl@lucid.com>]

re: The invokable functionality should have been made a function in its 
    own right, and the body of the method should have been a call to that 
    function.  
    . . . 
    The "problem" with what I say here is that the modularity has to be 
    worked out in advance.  I wouldn't allow people to reach inside an 
    existing program and, without changing the source code of that program, 
    pull out some functionality that they want, but which was not packaged 
    into a function by the author of that program.  

Well that's precisely the "rub".  The object-oriented approach is that
Programmer A's interface, which includes a listing of the methods and
their signatures, should be usable by programmer B without having to
delve into the source code (as I ultimately wound up doing for Kim!)

However, the unit of functionality needed by this very temporary patch 
was the effective method for specializers <C1, C2, ...>; and by all that
is holy in CLOS and OO languages in general, that cannot be packaged
out into a function by any of the various method's authors.

This is not the first time such a need was perceived.  Last summer 
(of 1989) some guy from a European research center was starting to port 
an application from their own home-grown Object-Oriented system into 
Lucid's CLOS, and found a low-frequency place where APPLY-METHOD was 
just the cat's meow.  Although I very much dislike the word COMPUTE in 
COMPUTE-EFFECTIVE-METHOD  (I would prefer something like FIND, or GET, or 
whatever ... but who cares),  it would seem that these two might go 
hand-in-hand towards satisfying this perceived need for the very 
ocasional "delegation."



-- JonL --