5 ms·

In a purely linguistic sense, the phrase "Object Oriented" does have some affinity to single dispatch, because the dispatch is oriented around a single special

In a purely linguistic sense, the phrase "Object Oriented" does have some affinity to single dispatch, because the dispatch is oriented around a single special Object. "Message Oriented" flows well into multiple dispatch, as the entire message can be taken into account for determining the final method combination. This of course is related back to the notion of a language focusing on the nouns (Objects), or verbs (Methods, Messages): http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

catnaroek 11y ago
> "Message Oriented" flows well into multiple dispatch, as the entire message can be taken into account for determining the final method combination. I'm not sure about this. The metaphor is that you send a message to a specific recipient, and the recipient figures out, independently, how to behave in response to that message. So it still seems like single dispatch to me.
- white-flame 11y ago
  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

> "Message Oriented" flows well into multiple dispatch, as the entire message can be taken into account for determining the final method combination. I'm not sure about this. The metaphor is that you send a message to a specific recipient, and the recipient figures out, independently, how to behave in response to that message. So it still seems like single dispatch to me.

white-flame 11y ago
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.