 Message Object Oriented vs Function Object Oriented
started 7/22/2003; 10:31:28 PM - last post 7/23/2003; 7:54:31 AM
|
|
Chris Rathman - Message Object Oriented vs Function Object Oriented 
7/22/2003; 10:31:28 PM (reads: 1916, responses: 3)
|
|
| Message Object Oriented vs Function Object Oriented |
|
In a conversation in another forum, the question came up whether Smalltalk's messaging view of the interaction between objects has a correlary in the Static Typing world. Specifically, is the concept of capturing #doesNotUnderstand and doing creative dispatching something that's anathema to static type checking?
The Message oriented languages (of which I know Smalltalk and Objective C) make objects act essentially like servers - when messaged they can simply handle the message, ignore the message, forward the message, or signal a fault. The messages themselves are available as a chunk of data to examine, or modify as necessary.
Messages are sent to an object's handler ("method" if you like), or to #doesNotUnderstand: if no handler exists. What you want to do in there is your business but the default is to halt the process and slap a debugger around it... This mechanism makes possible a number of very powerful techniques that are simply beyond the ken of the average function calling language user.
...the message can be reified as data and manipulated, and the mapping between message and method is looser and can be something other than a simple name/signature mapping.
Posted to OOP by Chris Rathman on 7/22/03; 10:34:37 PM
|
|
|
|
Matt Hellige - Re: Message Object Oriented vs Function Object Oriented
7/23/2003; 7:19:52 AM (reads: 719, responses: 1)
|
|
|
From the same discussion:
If one carries the messaging perspective to it's logical conclusion, then one should also be prepared to enable messages that can be handled asynchronously - i.e. you send the message but do not wait for acknowledgement that the actions being taken in response to that message are completed. This should entail being able to queue messages, prioritize them, and acknowledge when the message has been handled. Don't know if Smalltalk handles this scenario, but it seems to be the logical path for viewing it as a message/server framework.
If this is so, then isn't the logical conclusion of "message-passing OO" actually Erlang? This is something that's occurred to me before, but this post really makes it crystal clear... How do other "MOO" fans feel about this?
|
|
Erik Terpstra - Re: Message Object Oriented vs Function Object Oriented
7/23/2003; 7:54:31 AM (reads: 692, responses: 0)
|
|
|
|
Daniel Yokomiso - Re: Message Object Oriented vs Function Object Oriented
7/23/2003; 9:50:36 AM (reads: 689, responses: 0)
|
|
|
Well if you treat everything in Erlang as a process, including numbers and lists, then you'll get there. Smalltalk fans love the ability to make everything an object behaving like a tiny computer. The logical conclusion would create something similar to Erlang but with a simpler message-passing protocol, probably like Occam.
The elegance of Smalltalk is based in it's simple, yet powerful syntax (message-passing in particular). It's impossible to achieve this using Erlang's message-passing syntax: we can define control structures as messages in Smalltalk (e.g. ifTrue:ifFalse:, whileTrue:, to:do:, etc.) but not in Erlang (the result wouldn't be "elegant").
|
|
|
|