On 2/12/12 4:11 PM, Julian Leviston wrote:
On 13/02/2012, at 6:01 AM, Kurt Stephens wrote:
If send(sel, rcvr, args) can decomposed into apply(lookup(sel, rcvr, args),
rcvr, args), then this follows:
Message.new(sel, rcvr, args).lookup().apply()
...
I don't follow why a "message" isn't simply a token.
> For example, in Ruby, a message is simply a symbol, is it not?
You are confusing the name of a method (its selector), used to locate
the method, for the message. The message contains the selector,
receiver, arguments, and in the case of Ruby, an optional block --
everything need to pass data and transfer control. The selector
represents many methods -- the actual behavior is in the method. In
some object systems (TORT) selectors and methods can be anonymous.
> One has to draw the line in the sand at some point.
> Why bother building an entire object for something which simply holds
reference to a Method name
> (or not, as the case may be)?
> In this case, the media *is* the message, is it not? ;-) or are
> you stipulating that a Message would know how to perform lookup and
call,
> and therefore warrants an entire class... the only issue here is that
of efficiency, isn't it?
Why draw a line at all? The elements of the message are already there,
at least in CRuby, but are buried in the C stack -- not visible to the
user in an organized manner. TORT allocates Message objects on the C
stack, however a Message object does not need to "exist" until it's
referenced.
In TORT, the receiver's method table implements lookup(msg) and the
located method implements apply(msg, rcvr, args...); in fact, all
objects in TORT implement apply(), most of them raise an error when
apply() is called (similar to Self's code slot). The message object,
not the receiver, is always the first implicit argument.
I could imagine Message implementing both lookup() and apply(), but it
could be delegated to any other object(s), or replacing the default
object responsible for send() with another that prints traces then
delegates to some other object.
Message.apply() could act like invoking a continuation. You could take
a Message, install it as a method somewhere and restart it.
Sorry if I'm asking really obviously answerable questions. Please bear with me.
I'm eager to learn.
Another question I have, is, how do you solve the obvious recursive quality of
having
> Message.new(sel, scr, args) and also then sending messages to the
message object?
> Is "new" the bottom-out point?
Read Ian Piumarta's "Open, extensible object models" (
http://piumarta.com/software/cola/objmodel2.pdf ).
At a certain level, send(), lookup() and apply() have bootstrap
implementations to break the infinite regress. TORT was directly
inspired by Ian's paper. MOS (written a while ago) has a very similar
object model and short-circuit. There is an object, well-known by the
system, that describes its self -- this is where the short-circuit lives.
A graph of TORT's object model is here:
http://kurtstephens.com/pub/tort/tort.svg . It's turtles all the way
down, er... um... to the right. The last turtle, the "method table", is
chewing its tail. :)
I'm not a fan of HTTP/SOAP bloat. The fundamentals are often bulldozed by it.
How about REST?
REST is not object messaging or HTTP.
-- Kurt
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
