[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Weirdness in Dylan spec
In article ... (Henry Lieberman) writes:
"If [the current symbol binding] contains a generic function, the
definition of the generic function must be consistent with the call
to 'define-generic-function', or and error is signaled"
This implies to me that typing:
(define-generic-function foo (x) ...)
(define-generic-function foo (x y) ...)
will generate an error.
I agree, this is one of the worst mistakes of CLOS, and I would be sad to
see it repeated in Dylan.
In OO languages such as Smalltalk, Flavors, Actors, etc. the name of
the "message" [= CLOS "generic function"] is merely a convention
between the sender and receiver. That is, different sender-receiver
pairs can use the same name with different argument lists without
conflict. Forcing global consistency means that choosing a new name must
take into account all existing names.
The sender and receiver metaphor works well only when all of the
message dispatch is based on the first argument to the function. It
becomes much hairier when multi-methods are used. For example,
consider the following:
(defmethod ship ((item package) &rest options)
(defmethod ship ((item package) (destination city) &rest options)
Being able to distinguish these two methods is very difficult, since
the number of required arguments are different in the two methods.
Since rest arguments are specified, a call to
(ship some-package some-city)
could potentially match either method. The person writing the method
call has no way to indicate whether some-city is a required parameter
(and thus available for dispatch) or one of the rest arguments (and
thus ancillary information). It was to avoid this and related sorts
of problem that the congruence of lambda-lists was introduced for
generic functions. The more complicated the rules for figuring out
which arguments are used to do method dispatch, the slower the
resulting method call. At some point, execution efficiency
considerations outweigh the advantages of more flexible functions.
Thomas A. Russ email@example.com
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292 (310) 822-1511