[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Weirdness in Dylan spec
- To: email@example.com
- Subject: Weirdness in Dylan spec
- From: Henry Lieberman <lieber@MEDIA-LAB.MEDIA.MIT.EDU>
- Date: Tue, 7 Jul 92 16:34:18 -0400
- Cc: firstname.lastname@example.org.COM, info-mcl@MEDIA-LAB.MEDIA.MIT.EDU
- In-reply-to: email@example.com's message of Tue, 07 Jul 92 11:58:13 -0700 <9207071907.AA18943@brazil.cambridge.apple.com>
"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.
Imagine a program to manage a database of sailors,
where (defmethod ship ((self sailor)) ...) returns the ship a sailor is on,
and now a database for Federal Express where you have
(defmethod ship ((self package) (destination city) &optional rush-p) ...)
The result is you have to program defensively in CLOS by naming everything
sailor-ship, fedex-ship, etc. and hoping those won't conflict. And this is
bad because you mention the names of specific classes and doesn't extend
nicely when you subclass these.
Packages are supposed to be the "official" solution for this, but
packages work so badly in CL, that it is not a good solution. Using
them for this purpose would multiply the number of packages
dramatically, forcing practically a package per class. Modules may not
be much better.