3 ms·

In Lisp/CLOS-style multiple dispatch, the method you call is not associated with any particular object. It's simply a dispatcher, and the objects are the param

In Lisp/CLOS-style multiple dispatch, the method you call is not associated with any particular object. It's simply a dispatcher, and the objects are the parameters/message contents. So you don't send a message to a recipient object, but dispatch it using a toplevel method name. I know that's a deviation from Kay's descriptions, but it meshes well with the examples of multiple dispatch that I've seen. Conceptually, "dispatch" can be understood as finding the recipient, not an after-receipt task.

catnaroek 11y ago
Yes, I know how CLOS works. It's certainly a powerful approach, but it doesn't strike me as terribly... umm... object-oriented. (0) In CLOS, as you say, methods are requests to the global environment to find the right behavior to perform on a list of arguments. In an object-oriented system, each object has its own behavior, and the rest of the program (that is, the environment) has no business knowing how it internally works. (1) In CLOS, anyone can tamper with any object's slots, and this isn't even discouraged. In an object-oriented system, the internal representation of an object can't be directly manipulated from the rest of the program. The behavior of an object is defined entirely in terms of how it responds to messages. That being said, you can do object-oriented programming with CLOS. It's just not the only, or even the main style that it supports. For more information, see: http://wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html http://wcook.blogspot.com/2012/07/proposal-for-simplified-mo...
- white-flame 11y ago
  > In an object-oriented system, each object has its own behavior, and the rest of the program (that is, the environment) has no business knowing how it internally works. I would say that describes Erlang-style message passing, or maybe JavaScript-style prototype OO. But in most "common OO" languages, I would say it's more correct that each class has its own behavior, not object. Of course, the hidden state of an object can parameterize the class's behavior. But still, there are many behaviors which differ based on the type or identity of their arguments, but aren't well suited to be encapsulated into said objects as they're equal peer parameters to the message, hence CLOS etc.

catnaroek 11y ago

Yes, I know how CLOS works. It's certainly a powerful approach, but it doesn't strike me as terribly... umm... object-oriented. (0) In CLOS, as you say, methods are requests to the global environment to find the right behavior to perform on a list of arguments. In an object-oriented system, each object has its own behavior, and the rest of the program (that is, the environment) has no business knowing how it internally works. (1) In CLOS, anyone can tamper with any object's slots, and this isn't even discouraged. In an object-oriented system, the internal representation of an object can't be directly manipulated from the rest of the program. The behavior of an object is defined entirely in terms of how it responds to messages. That being said, you can do object-oriented programming with CLOS. It's just not the only, or even the main style that it supports. For more information, see: http://wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html http://wcook.blogspot.com/2012/07/proposal-for-simplified-mo...

white-flame 11y ago
> In an object-oriented system, each object has its own behavior, and the rest of the program (that is, the environment) has no business knowing how it internally works. I would say that describes Erlang-style message passing, or maybe JavaScript-style prototype OO. But in most "common OO" languages, I would say it's more correct that each class has its own behavior, not object. Of course, the hidden state of an object can parameterize the class's behavior. But still, there are many behaviors which differ based on the type or identity of their arguments, but aren't well suited to be encapsulated into said objects as they're equal peer parameters to the message, hence CLOS etc.