[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Looking for an equivalent of :UNCLAIMED-MESSAGE
- To: commonloops.pa%xerox.com%att.uucp@att.att.com
- Subject: Looking for an equivalent of :UNCLAIMED-MESSAGE
- From: lgm%ihlpf.uucp@att.att.com
- Date: Fri, 29 Sep 89 16:04 CDT
- >from: ihlpf!lgm (Lawrence G Mayka +1 312 713 5166)
- Redistributed: commonloops.pa
I'm preparing to port some software from Symbolics New Flavors to
CLOS. The case in question is an :UNCLAIMED-MESSAGE method defined
on a particular flavor. The only similar functionality in CLOS
seems to reside in the NO-APPLICABLE-METHOD generic function, for which
one may define methods. To obtain behavior similar to :UNCLAIMED-MESSAGE
for a class MY-CLASS, I would need to define a method such as
(defmethod no-applicable-method ((gf standard-generic-function)
(obj my-class) &rest args)
...)
Unfortunately:
a) I remember some debate in this mailing list as to whether it was
proper (i.e., whether correct behavior was guaranteed) to define
a method of a "specified generic function" such as NO-APPLICABLE-METHOD
on a "specified class" such as STANDARD-GENERIC-FUNCTION.
The default behavior provided by PCL is unspecialized (i.e., specialized
on T), by the way.
b) NO-APPLICABLE-METHOD is defined to take only one required (and
hence specializable) argument, the generic function. I need to
specialize on the second argument, namely the first argument to the
generic function. This gets back to a question I brought up once
before: Does it make any sense for a generic function to take *no*
required arguments? If not, why can't NO-APPLICABLE-METHOD be
defined to take a second required argument (so that I can
specialize on it)? (Actually, a reason for a generic function
to take no arguments might be to accept :BEFORE, :AFTER, and :AROUND
methods, but this doesn't seem to work in 5/23 PCL anyway.
Maybe it should?)
If (a) is not a problem, I can at least define my method to
specialize on STANDARD-GENERIC-FUNCTION and then look at the next
argument myself (a la currying). If (a) is a problem, I see no
solution other than resorting to a new metaclass for all my generic
functions.
Do I have all of this right?
Lawrence G. Mayka
AT&T Bell Laboratories
lgm@ihlpf.att.com
Standard disclaimer.