J
james_b
I ran across a thread on iwethey.org, where Jim Weirich wondered about
message-object-oriented (not sure if that's a double-hyphenated word or
not) and function-object-oriented languages.
<quote
cite='http://z.iwethey.org/forums/render/content/show?contentid=110693'>
Message Object Oriented vs Function Object Oriented
In the "Great OO Argument Closer" thread, Todd Blanchard shared these
thoughts from Alan Kay ...
[Kay] thinks people have largely missed the point. Its not so much that
there are classes and objects, but that there is a messaging system and
every object may be thought of as a server. This is markedly different
from the function calling behavior of the so-called "normal" [...]
languages.
Given that there are Message Object Oriented (MOO) and Function Object
Oriented (FOO) languages, I have two questions that I think would be
interesting to explore:
(1) What is the essential feature or features that differentiate a MOO
language from FOO language? (Is it Duck Typing? Dynamic VS static
typing? Keyword messages?)
(2) Kay obviously prefers a MOO language. What are the inherit
advantages of MOO over FOO? How about advantages of FOO over MOO?
</quote>
This struck a chord with me because I've wondered about the syntax for
sending messages to objects. The OO languages I'm familiar with all seem
to put the focus on the receiver rather than the message, in such a way
is to imply that the two are necessarily coupled:
reciever.message( arg1, arg2 )
Maybe because I read left to right, or because I first learned
procedural programming languages, but this format strongly suggests that
the message is part of the object. It doesn’t help, of course, that
pretty much all the popular literature conflates message with method,
largely I suppose because that's pretty much how it is in Java.
I wondered if a syntax that emphasized the message would help me think
about OO programming differently. I wanted something like
message obj
or
message obj ( arg1, arg2 )
or
message( arg1, arg2 ) -> obj
I set about finding a way to do it in Ruby, and came up with an addition
to the Symbol class. I wasn't sure if I wanted to have a full-blown
Message class; I liked the idea that one could just type the message to
send without having to go create a special object for it. The Symbol
syntax makes this very natural
class Symbol
def >>( *args )
ary = []
arglist = (block_given? ? yield : nil )
args.each{ |obj|
begin
ary << dispatch( obj, arglist )
rescue Exception
ary << $!.clone
end
}
ary
end
def dispatch( obj, arglist )
return obj.send(self.to_s, *arglist) if arglist && (arglist.size>0)
obj.send( self.to_s )
end
end
This allows expressions like:
:some_message.>> obj
:some_message.>>( obj1, obj2 )
:some_message.>>( obj1, obj2 ){ [ arg1, arg2, arg3] }
Any message string, instantiated as a Symbol, can be dispatched to a
list of objects, along with a set of message arguments. The results
come back as an array.
It shouldn't be too hard to add some way to pass object criteria instead
of a list of specific objects, such that you could send a message to all
objects in ObjectSpace that are derived from a particular class, or
respond to some particular method, or have the string "Foo" in their
class name. In way, then, you could "broadcast" a message and collect
the results from all recievers meeting some criteria.
This is all good fun, but so far it hasn't switched on too many
pragmatic light bulbs for me. Part of me thinks this is because I just
haven't spent much time working with; I'm too adapted to more common
programming conventions. But another part of me thinks this may just be
another "Look what you can do in Ruby" trick.
Any thoughts on this sort of syntax, or this specific Ruby hack, or
MOO/FOO in general?
What other syntax would one need for a true message-oriented programming
lanaguge?
(BTW, there's a very good history of Smalltalk article by Alan Kay
available at
http://www.metaobject.com/papers/Smallhistory.pdf. It's a reprint from
an ACM publication. There's also a good Kay quote about messaging at
http://www.omnigroup.com/mailman/archive/macosx-dev/2000-July/002850.html)
James Britt
message-object-oriented (not sure if that's a double-hyphenated word or
not) and function-object-oriented languages.
<quote
cite='http://z.iwethey.org/forums/render/content/show?contentid=110693'>
Message Object Oriented vs Function Object Oriented
In the "Great OO Argument Closer" thread, Todd Blanchard shared these
thoughts from Alan Kay ...
[Kay] thinks people have largely missed the point. Its not so much that
there are classes and objects, but that there is a messaging system and
every object may be thought of as a server. This is markedly different
from the function calling behavior of the so-called "normal" [...]
languages.
Given that there are Message Object Oriented (MOO) and Function Object
Oriented (FOO) languages, I have two questions that I think would be
interesting to explore:
(1) What is the essential feature or features that differentiate a MOO
language from FOO language? (Is it Duck Typing? Dynamic VS static
typing? Keyword messages?)
(2) Kay obviously prefers a MOO language. What are the inherit
advantages of MOO over FOO? How about advantages of FOO over MOO?
</quote>
This struck a chord with me because I've wondered about the syntax for
sending messages to objects. The OO languages I'm familiar with all seem
to put the focus on the receiver rather than the message, in such a way
is to imply that the two are necessarily coupled:
reciever.message( arg1, arg2 )
Maybe because I read left to right, or because I first learned
procedural programming languages, but this format strongly suggests that
the message is part of the object. It doesn’t help, of course, that
pretty much all the popular literature conflates message with method,
largely I suppose because that's pretty much how it is in Java.
I wondered if a syntax that emphasized the message would help me think
about OO programming differently. I wanted something like
message obj
or
message obj ( arg1, arg2 )
or
message( arg1, arg2 ) -> obj
I set about finding a way to do it in Ruby, and came up with an addition
to the Symbol class. I wasn't sure if I wanted to have a full-blown
Message class; I liked the idea that one could just type the message to
send without having to go create a special object for it. The Symbol
syntax makes this very natural
class Symbol
def >>( *args )
ary = []
arglist = (block_given? ? yield : nil )
args.each{ |obj|
begin
ary << dispatch( obj, arglist )
rescue Exception
ary << $!.clone
end
}
ary
end
def dispatch( obj, arglist )
return obj.send(self.to_s, *arglist) if arglist && (arglist.size>0)
obj.send( self.to_s )
end
end
This allows expressions like:
:some_message.>> obj
:some_message.>>( obj1, obj2 )
:some_message.>>( obj1, obj2 ){ [ arg1, arg2, arg3] }
Any message string, instantiated as a Symbol, can be dispatched to a
list of objects, along with a set of message arguments. The results
come back as an array.
It shouldn't be too hard to add some way to pass object criteria instead
of a list of specific objects, such that you could send a message to all
objects in ObjectSpace that are derived from a particular class, or
respond to some particular method, or have the string "Foo" in their
class name. In way, then, you could "broadcast" a message and collect
the results from all recievers meeting some criteria.
This is all good fun, but so far it hasn't switched on too many
pragmatic light bulbs for me. Part of me thinks this is because I just
haven't spent much time working with; I'm too adapted to more common
programming conventions. But another part of me thinks this may just be
another "Look what you can do in Ruby" trick.
Any thoughts on this sort of syntax, or this specific Ruby hack, or
MOO/FOO in general?
What other syntax would one need for a true message-oriented programming
lanaguge?
(BTW, there's a very good history of Smalltalk article by Alan Kay
available at
http://www.metaobject.com/papers/Smallhistory.pdf. It's a reprint from
an ACM publication. There's also a good Kay quote about messaging at
http://www.omnigroup.com/mailman/archive/macosx-dev/2000-July/002850.html)
James Britt