Re: operation naming conventions

[Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>]

    Date: Fri, 1 Aug 86 05:10 PDT
    From: Dan Carnese <Carnese@SRI-KL>

	    From: Dan Carnese <CARNESE@SRI-KL.ARPA>
    
	    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.
    
	From: Gregor Kiczales <Gregor.pa@Xerox.COM>

	I thought the convention in question was the one that Moon and I had
	been using for naming generic functions.  That convention is NOT "to
	prepend the name of the class to the name of operation associated with
	it".  That convention IS "to (usually) prepend the name of a protocol to
	the name of the operation".

	So changing the name of a class has no effect on the name of generic
	functions.

	I think it is clear that no default value for conc-name is ever going to
	be the basis for a really useful convention for naming generic
	functions.  That is why I didn't think we were talking about the
	*convention* you would get if you just used the default value of
	conc-name (whatever it might be) all the time.

I agree with Gregor on this point.  When you're using object-oriented
programming for its real intended purpose, and therefore there are many
classes that implement a given protocol, then defaulting the conc-name
from the class name is not a good convention.  Moon points out that it
might be reasonable for beginners who are only using one class for a
protocol; I can see this point, but I'm afraid that this isn't good
preparation for such users to learn how to do more sophisticated things
with protocols, so I'm not sure it's a good idea.

    I guess we're all being pretty sloppy about just what we mean by
    "protocol".  

So far, it seems to me that Gregor and Moon and I have been using the
term consistently.

		 An extreme position, which I had implicitly taking in this
    discussion, is that whenever you introduce a new operation you are
    implicitly defining a new protocol.  

I don't understand why you'd say this.  When a new operation is created,
then either it is being added to some existing protocol, or it is part
of a new protocol.

					 Maybe you'll change its specification
    later (i.e., a protocol is different from a contract), but in the meantime
    another person can add an alternative implementation to what you've done
    and have the two coexist.

A protocol isn't very different from a contract; it's a set of contracts,
actually.  Yes, there can be many implementations.  I'm not sure what you'r
getting at.

    But even if you don't buy that view, the "protocol-name-prepending"
    convention is a bad idea for essentially the same reasons that the
    "class-name-prepending" convention is.  All the arguments against the
    latter now apply to protocol renaming and moving operations around
    protocols.  That's the really important part of experimental system design,
    and I don't want that activity to be hampered in any way.

I do not buy this at all.  Changing the name of an operation that's part
of a protocol is like changing the name of any function that's part of
an external interface.  If I advertise that people can call READ-CHAR,
and then change the name to something else, of course all of the callers
must be found and changed.  How could it be otherwise?  This is equally
true whether READ-CHAR is a generic operation of a protocol, or just a
plain old Lisp function.

    I hope it's now clear that I'm claiming that prepending *any* string to a
    operation name is a bad idea.

I do agree that you should be able to rearrange the insides of the
implementation of a class, moving things among the component classes,
without any visible change to the calling modules.  I agree that the
existing conc-name default gets in the way of that, because the names of
the operations are changed when you move the methods around, and you
have to be careful to remember to override the default conc-name, etc.
This is because names of generic operations are part of a protocol,
whereas names of classes are hidden internal implementation details, and
therefore names of classes should not be used to form names of generic
operations.

However, protocol names (if there were such a thing) are completely
different.  They are part of the external interface.  They cannot be
renamed at will, invisibly to the caller; that is logically impossible.
A convention of some sort that involved formation of generic operation
names by concatenating protocol names with other strings does not create
any particular problems; it's just shorthand for writing the whole name
out every time.