[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: format for description of generic functions in chapter 2
Actually, I disagree with one detail of what Gregor said. I can't understand
why lambda-list congruence should be restricted to standard generic functions
and standard methods. To me lambda-list congruence seems equally applicable
to all generic functions and methods, and furthermore it's hard to see how
generic functions could work or users could call them if there wasn't
lambda-list congruence. Thus I think congruence is part of the contract of
add-method, and should not be demoted to association with a
I (Gregor) still disagree with you about this. More in a separate
I will be interested in seeing what prompted Gregor to disagree. It
seems to me that it is bad if you have to know the class of a generic
function, and find out about the lambda congruence rule for this class,
in order to know that your program is calling it properly. I doubt that
you will gain much power from changing the lambda list congruence rule
and it seems that this "flexibility" will bring confusion.
Here's the big problem with this new breakout of methods and generic
functions: We are uncovering a significant amount of confusion about
what is the contract of a generic function, versus what is a property
of particular methods for that generic function. In effect all of
the issues and uncertainties surrounding meta-objects have suddenly
leaked into the part of the document that we thought was almost
finished. I'm really opposed to that because I think it sets us back
a long way. It's really not necessary to resolve all those issues
to get something that is entirely useful to someone who is just going
to call these generic functions and not define new methods for them.
On the other hand, I do think the introduction of the method signatures
was a good idea, and I think the format as described in the quotation
from RPG above is a good idea. If we can keep the documentation in the
style of the sample class-changed writeup, I'll be happy with the new
format, but if we're going to get bogged down in all these modularity
issues, I want no part of it.
Its true that this new breakout causes us to confront some meta-object
stuff which we don't really want to have to work out in the next 5 days.
But, it may be alright if we just take our best stab at it and then fix
it up later. Here's why. We believe that for the time being, the only
kind of programming we are really sanctioning is programming that calls
these generic functions (in cases like add-method). In these cases, we
should take our best shot, but if in the course of writing the meta spec
we decide we need to move something from method to gf or vice versa we
can. Because as far as the user who just calls generic functions like
add-method, the behavior of the generic function as a whole will be
unchanged. As a point of strategy, where we are unsure, behavior should
be ascribed to the generic function rather than the one of the methods.
I like this strategy. I don't have any problems with the agreement
reached in each case.