my comments on 2/2/87 draft of functi

[Gregor.pa@Xerox.COM]

Here are a bunch of comments on the 2/2 draft of functi.  Also scattered
in here for your reading pleaser are my proposals for how to solve some
other problems like:

  - initialization
  - setf generic function argument lists
  - indentation convention for defclass
  


--
add-method (and remove-method)

still say that it accepts symbols or a list of (SETF <symbol>) as
argument.  I proposed and Moon agreed that it should only accept generic
function objects as its first argument.  In a separate message I will
mail out a proposal for ensure-generic-function which is needed as part
of this change.  For the time being I suggest that
ensure-generic-function be added to functi to "hold a place for it".


--
call-next-method

(2nd paragragh under purpose, end of next to last sentence)
The phrase "otherwise it is the next most specific primary method" is
wrong.  It should be something like "otherwise it is the effective
method which would have been called had there been no :around methods".

(1rst paragraph under remarks)
The last sentence would be more clear if it read:
  Neither argument defaulting, nor the use of setq, nor rebinding the
variables with the
  same names as parameters affects the values call-next-method passes to
the method it
  calls.

--
change-class

(1rst para under purpose, 3rd sentence)
should say the class-changed generic-function is called.


I don't like the indenting of the defclass forms in the examples here.
I would like to see defclass dorms indented as follows.

If there are no slots and no options, it should be all on one line:

(defclass foo () ())
(defclass bar (foo) ())

If there are slots or options, the name and supers should be on the
first line, then the slot descriptions should be indented under the c in
defclass, then the options should be indented under the e in defclass.
This puts the slot-descriptions in a place that doesn't move when there
are supers, and makes a nice "line" between them and the options.

(defclass foo ()
    ((a 1)
     (b 2)))

(defclass bar (foo)
    ((c 3)
     (d 4))
  (:accessor-prefix bar-))

(defclass baz (bar)
    ()
   (:metaclass mumble))

--
class-of

last paragraph on the page (under remarks)
shouldn't this say that class-of returns a class at "least as specific"
as specified according to figure 1-2.  The difference is that what is
written says that class-of will always return a class the user has heard
of, what I am suggesting is that class-of will always return a subclass
of a class the user has heard of.

--
defclass

(2nd para under purpose)
"that FUNCTIONS be automatically generated" should be "that METHODS
automatically BE DEFINED ON GENERIC-FUNCTIONS to .." or something like
it.  This same mistake occurs later in the paragraph.  It looks like
someone just lifted this from some defstruct documentation somewhere.

The 3rd (and last) paragraph under purpose wouldn't be needed if we
could figure out this type to class mapping better and explain it
better.

Under Syntax:

the abbreviation for having an initform with no other slot options
(<slot-name> <initform>) is missing.

the argument to accessor-prefix and friends is described as string or
symbol.  Its always a symbol, its sometimes NIL.

Under arguments:

(2nd para) it doesn't say that the superclass-name arguments must name a
class of class standard-class.  This may not be the right place to say
it, but I can't find this anywhere.

(3rd para) "there must not be any duplicate slot-names" Or else what?
Perhaps "If there are any duplicate slot-names an error is signalled"
would be better.

Under the description of class-options, the argument to :accessor-prefix
and friends is also listed as a string-or-symbol.

Under values:
I thought we decided all these DEF forms were going to return the object
they defined?

Under remarks:

(6th para after the 4 bullets), there is a sentence missing before the
last sentence.  The last sentence reads "No other slot option may appear
more than once.."  The missing sentence would say which slots options
could appear more than once.

--
defgeneric-options-setf (and defmethod-setf)

Let me say once again, that in order for the user to be able to add
methods to a setf-generic-function with add-method, we must document the
convention which defgeneric-options-setf and defmethod-setf use to pass
the new-value argument to the setf generic function.  I believe the
convention we must use is that the new-valeu argument to setf becomes
the first argument to the generic function.  Using this convention, the
user could write the following piece of code.

(defgeneric-options-setf foo (moving-obj) (new-foo))

(add-method (get-setf-generic-function 'foo)
            (make-method :specializers (list (class-named 't)
(class-named 'plane))
                         :function #'(lambda (new-value plane) ..)))

Unless anyone objects to this convention or to documenting it, it should
be placed in the document either in concepts or under defmethod-setf or
defgeneric-options-setf or some combination and cross-referenced etc.

If someone needs help explaining this let me know.

--
get-method

The specializers argument needs to be changed to be a list of
class-objects or (QUOTE <datum>).

get-method should not error in the case where no such method exists.
get-method is the only way to see if such a method exists, it should
return nil if there isn't one.  Once get-method is changed this way,
add-method and remove-method's error conditions are good.


--
invalid-method-error and method-combination-error

I still don't like having these as separate functions.  Could we put a
note saying that if the condition system is adopted before this
proposal, these functions would be replaced by descriptions of the
appropriate condition to signal?

--
make-generic-function and make-method

I thought we had decided to remove this from the spec.  I believe the
only thing holding that up is a decision about the initialization
protocol.  Since nothing is happening with the initialization protocol,
I plan to write up a revised version of my Strawman, incorporating the
comments I have received from Moon and as Linda to put it in the spec.
Afterwards, I think we should replace make-generic-function and
make-method with descriptions of the appropriate arguments to pass to
make-instance to make a method a generic-function (and a class).

--
with-slots

The first paragraph under arguments should probably say the instance
form must evaluate to an object of class standard class.  The
meta-object protocol chapter will describe how to extend with-slots to
work with instances with other meta-classes.