CL's generic functions are not a superset of message passing, and neither is message passing a superset of generic functions. Message passing allows an implementation of doesNotUnderstand or noSuchMethod or similar, whereas generic functions don't.

Not that I think that is a good trade-off vs all the advantages of generic functions. Besides, the things people accomplish with doesNotUnderstand are much better accomplished with macros anyway.

>CL's generic functions are not a superset of message passing

I would say they are. Generic functions can dispatch on a single object if they want to.

As far as doesNotUnderstand, most OO languages don't support it anyway. Further, while I can't find it just now, I seem to recall MOP or CLOS itself providing doesNotUnderstand functionality. You could also either provide a doesNotUnderstand specialization on T, or set up a single handler for it.

If you insist on similar semantics to Smalltalk/Ruby/JS(?) then it wouldn't be hard to use MOP to create a new kind of method dispatch that simply turned the call for a failed specialization lookup into a does-not-understand call as a last step instead of signaling error.

Message passing OO like in Ruby and Smalltalk means that an object receives messages that it can interpret in any way it wants. For example you can create an object that prints the messages to the console:

    class Foo
      def method_missing(meth, *args)
        puts "#{meth}(#{args.join(',')})"
      end
    end

    f = Foo.new
    f.foo() # prints foo()
    f.bar(1,2) # prints bar(1,2)
    f[2] = "hello" # prints []=("hello")

You can't do this with CLOS because methods are lexically scoped.

Why is this interesting? For example because with this you can implement transparent remote objects. When you make a call on the object, it makes a network request, on the other computer the call is made and the result is sent back over the network, and finally the original method call returns. So the code would end up looking something like this:

    # server on ip 1.2.3.4
    shared_object = Array.new
    shared_object[3] = "good morning"
    serve_object("foo", shared_object)

    # client
    remote_object = RemoteObject.new("1.2.3.4", "foo")
    remote_object.length        # makes a network call to 1.2.3.4 and computes the length
    remote_object[3]            # returns "good morning"
    remote_object[3] = "hello"  # sets the index 3 to the string "hello"
    # code in the server can now access shared_object[3] and it will get "hello"

Ruby actually has such a library. It's called Drb.

All in all, I think that generic functions are better than message passing, but generic functions are definitely not strictly more powerful.