Weirdness in Dylan spec

[Steve Strassmann <straz@cambridge.apple.com>]

>Date: Tue, 7 Jul 92 16:34:18 -0400
>From: Henry Lieberman <lieber@MEDIA-LAB.MEDIA.MIT.EDU>
>To: nathan@akbar.teleos.com
>Cc: oodl.sig@applelink.apple.COM, info-mcl@MEDIA-LAB.MEDIA.MIT.EDU
>Subject: Weirdness in Dylan spec
>
>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.
>

I disagree - this may be a matter of honest difference of opinion.
Leaving efficiency considerations aside, I see it as a question of 
code clarity.

The two versions of "ship" above are quite different, and I personally
prefer to see them separated by a package or module boundary. 
What happens when you call (ship sailor-sam seattle)? I don't think
having subtly different arglists to different SHIP methods is enough 
to keep the meaning of this code clear.

So OK, there's some problems with CL packages, and we hope to address 
those in Dylan with modules. I don't see why such a proliferation of 
packages is necessary and/or bad. In general these conflicts will be 
relatively rare, and when they arise they should be explicitly dealt
with.