[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: operation naming conventions
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 guess we're all being pretty sloppy about just what we mean by
"protocol". 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. 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.
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 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 hope it's now clear that I'm claiming that prepending *any* string to a
operation name is a bad idea.
Enough for now. See you all in Boston.
-- Dan