[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issues raised by comments on chapter 2
- To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Subject: Issues raised by comments on chapter 2
- From: Gregor.pa@Xerox.COM
- Date: Wed, 4 Nov 87 10:58 PST
- Cc: common-lisp-object-system@SAIL.Stanford.EDU
- In-reply-to: The message of 4 Nov 87 10:18 PST from Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Line-fold: no
Date: 04 Nov 87 10:18 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The spirit of object-oriented programming, I guess, states that users can
define whatever the hell they like for methods. The spirit of reasonable
abstraction states that users should be required to choose their own
random names for their random methods, leaving ADD-METHOD for methods that
add methods to generic functions.
I propose, then, that the policy of CLOS be that purpose statements be promoted
to apply to generic functions whenever feasible.
Whenever 'reasonable' is more like it. For example, the purpose of the
add-method generic function is to add a method to a generic function.
If there is already a similar method an error is signalled. The generic
function is completely updated to know about the new method.
The particular method on (standard-gf standard-method), has some of its
own private behavior as well. For example, it defines what it means for
methods to be similar in this case (same qualifiers and specializers).
It also defines what the lambda-list congruence rules will be.
So its not a matter of whenever feasible, its a matter of reasoning it
out on a case by case basis.
``Any implementation of the \CLOS\ is allowed to provide other methods
for the generic functions described in this chapter.''
I think this should be changed so that we can make this statement about
some generic functions and not others. Even in the cases where we say
its OK to have more methods we are going to want some language for
placing some restrictions on where there could be methods. For example,
in print-object, an implementation should be free to have methods on as
many of its pre-defined classes as it likes, but it should not be
allowed to define print-object methods on user-defined classes behind
said user's back.
Of course what is really causing all the problem here is that none of us
has any real idea what a 'protocol' is or how to specify one.