3 ms·

I have to admit I still have basically no idea what he's talking about when he says 'messaging'. A practical example would be useful for us non-CS-degree progra

by stinos 10y ago

I have to admit I still have basically no idea what he's talking about when he says 'messaging'. A practical example would be useful for us non-CS-degree programmers who don't speak any of the CS lingo.

pdkl95 10y ago
The idea is to replace "calling a function" with "sending a message". Traditionally a function call is fixed at compile time (with some exceptions such as function pointers). In C a function is just an address; if we want to call foo(), we must have that function available at address &foo. C++ added flexibility by allowing there to be multiple functions called foo() with and a set of vtables[1] that store the actual (C-style) address. Other variations exist, but all of these traditional styles map function calls to specific code that runs every time the function is called. Message change all of that. Instead of vtables (or similar) obj = create_foo() # instead of calling foo's bar() function directly, e.g. foo_bar(obj) # or perhaps obj.bar() ... we send a message by name of the function we want to call to the object itself obj = create_foo() obj.send_message("bar") # if function args are needed, include them as an array obj.send_message("baz", [42, "quux"]) The idea is that while the message can be effectively the same as a function call, it doesn't have to be. In a proper OO language, this message sending is handled automagically by the syntax. # instead of handling the messages directly, e.g. obj.send_message("bar") # the language does that for you when you call obj.bar() # in some languages, these are equivalent In many cases the "foo" class above will handle the message "bar" by running the appropriate function, but that isn't required. For example, in ruby when no function exists for a given message, the raw message is send to the #method_missing function. class Foo def method_missing(name, *args, &block) puts "#{self.inspect} I was sent message #{name.inspect} with args #{args.inspect}" end end >> obj = Foo.new => #<Foo> >> obj.bar() #<Foo> I was sent message :bar with args [] => nil >> obj.any_name_we_want() #<Foo> I was sent message :any_name_we_want with args [] => nil >> obj.any_name_we_want("args", "are", "optional") #<Foo> I was sent message :any_name_we_want with args ["args", "are", "optional"] Thinking of "obj.method()" as a message instead of only a function is much more flexible. [1] https://en.wikipedia.org/wiki/Virtual_method_table https://en.wikipedia.org/wiki/Virtual_method_table
- stinos 10y ago
  thanks, that was a nice explanation
michaelscott 10y ago
For me there's a disconnect in the handling. So in a traditional approach, you write one function that takes in input and spits out an output (called, say, FUNCTION_A). Then you have another function (FUNCTION_B) that maybe does some stuff and then calls FUNCTION_A with an internal variable and bam you're done. In messaging, FUNCTION_B doesn't call FUNCTION_A. It just shouts out (or sends a message containing) something like "I need to turn my internal variable into a given output". Somewhere in the application will be a process that listens out for just that message and then does something in response to it. So you have all these modules (or cells in some examples) that are shouting out things and then you have other cells (or a single brain) that take in all the messages that are being shouted and do stuff based on the content of the message. You could think of a stock market trading floor (with a whole bunch of people scrambling and shouting stuff, although obviously much more orderly in a program) or the cells in your body that send messages to your brain (like cells in your fingers sending "the human is putting his hand on a hot stove, tell him to take it off before us little cells die" and then your brain - and you - react).
aryehof 10y ago
Imagine two solutions to a problem. One has a main procedure that orchestrates itself and other code to work things out and do things. This is the way most people organize their problems into code. The second is a set of independent intelligent concepts (objects) that work together to work things out and do things. The objects work together only by sending messages to each other. There is no central code orchestrating them into a solution. If you want an example, consider two tennis players and a ball. How would your represent them hitting the ball to each other in code?

by stinos 10y ago

pdkl95 10y ago

The idea is to replace "calling a function" with "sending a message". Traditionally a function call is fixed at compile time (with some exceptions such as function pointers). In C a function is just an address; if we want to call foo(), we must have that function available at address &foo. C++ added flexibility by allowing there to be multiple functions called foo() with and a set of vtables[1] that store the actual (C-style) address. Other variations exist, but all of these traditional styles map function calls to specific code that runs every time the function is called. Message change all of that. Instead of vtables (or similar) obj = create_foo() # instead of calling foo's bar() function directly, e.g. foo_bar(obj) # or perhaps obj.bar() ... we send a message by name of the function we want to call to the object itself obj = create_foo() obj.send_message("bar") # if function args are needed, include them as an array obj.send_message("baz", [42, "quux"]) The idea is that while the message can be effectively the same as a function call, it doesn't have to be. In a proper OO language, this message sending is handled automagically by the syntax. # instead of handling the messages directly, e.g. obj.send_message("bar") # the language does that for you when you call obj.bar() # in some languages, these are equivalent In many cases the "foo" class above will handle the message "bar" by running the appropriate function, but that isn't required. For example, in ruby when no function exists for a given message, the raw message is send to the #method_missing function. class Foo def method_missing(name, *args, &block) puts "#{self.inspect} I was sent message #{name.inspect} with args #{args.inspect}" end end >> obj = Foo.new => #<Foo> >> obj.bar() #<Foo> I was sent message :bar with args [] => nil >> obj.any_name_we_want() #<Foo> I was sent message :any_name_we_want with args [] => nil >> obj.any_name_we_want("args", "are", "optional") #<Foo> I was sent message :any_name_we_want with args ["args", "are", "optional"] Thinking of "obj.method()" as a message instead of only a function is much more flexible. [1] https://en.wikipedia.org/wiki/Virtual_method_table https://en.wikipedia.org/wiki/Virtual_method_table

stinos 10y ago
thanks, that was a nice explanation

michaelscott 10y ago

For me there's a disconnect in the handling. So in a traditional approach, you write one function that takes in input and spits out an output (called, say, FUNCTION_A). Then you have another function (FUNCTION_B) that maybe does some stuff and then calls FUNCTION_A with an internal variable and bam you're done. In messaging, FUNCTION_B doesn't call FUNCTION_A. It just shouts out (or sends a message containing) something like "I need to turn my internal variable into a given output". Somewhere in the application will be a process that listens out for just that message and then does something in response to it. So you have all these modules (or cells in some examples) that are shouting out things and then you have other cells (or a single brain) that take in all the messages that are being shouted and do stuff based on the content of the message. You could think of a stock market trading floor (with a whole bunch of people scrambling and shouting stuff, although obviously much more orderly in a program) or the cells in your body that send messages to your brain (like cells in your fingers sending "the human is putting his hand on a hot stove, tell him to take it off before us little cells die" and then your brain - and you - react).

aryehof 10y ago

Imagine two solutions to a problem. One has a main procedure that orchestrates itself and other code to work things out and do things. This is the way most people organize their problems into code. The second is a set of independent intelligent concepts (objects) that work together to work things out and do things. The objects work together only by sending messages to each other. There is no central code orchestrating them into a solution. If you want an example, consider two tennis players and a ball. How would your represent them hitting the ball to each other in code?