operation naming conventions

[Dan Carnese <CARNESE@SRI-KL.ARPA>]

    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    Renaming classes, whether they add new operations or not, causes no
    problems with this conc-name convention.  

The convention in question is to prepend the name of the class to the name
of operations associated with it, e.g., window-draw-line.  If we decide to
change the name of class, we must then change the text of all the programs
using operations of the class, e.g., all window-using programs.  If the
name of the operation did not include the name of the class, e.g.,
draw-line, nobody's code would need to change.

                                              But renaming classes can cause
    lots of other problems.  What about all the defmeth (or defmethod or
    whatever) forms which mention the name of that class?  Some programming
    environments are able to find all those method definitions and update
    them, but in other environments the progarmmer will have to do a lot of
    work to properly update each place which mentioned the name of the
    class.

Sure, this can be a problem as well, and better programming environments
can mitigate it.  But I'd rather avoid the problem entirely.

    I also don't see what moving methods around in a class lattice has to do
    with this conc-name convention.

If an operation is moved from one class to another, the convention requires
that its name be changed.  All user programs must then be modified.

    It seems to me that the problems with both renaming classes and moving
    methods are problems with having the environment understand what you are
    doing.  The environment must have some knowledge of what classes and
    methods really are.  I can't resist saying that the best way for the
    environment to represent this meta-level information is to have the
    classes and methods themselves be objects as they are in CommonLoops.

Of course, having classes and methods be objects makes it easier to build
more powerful environments for dealing with them.  But the real problem
here is that of modifying all the programs everywhere that use a protocol.
To fully solve the problem, we would need a Pie-like system incorporating
entire communities (e.g., all Common Lisp users) where new versions with
``incompatible changes'' were distributed with programs that would
automatically rewrite the old code.  A wonderful vision, but ...

-- Dan
-------