On 13/02/2012, at 6:01 AM, Kurt Stephens wrote: > On 2/12/12 11:15 AM, Steve Wart wrote: > >> Can the distributed computation model you describe be formalized as a >> set of rewrite rules, or is the "black box" model really about a >> protocol for message dispatch? Attempts to build distributed messaging >> systems haven't been particularly simple. In fact I consider both CORBA >> and Web Services to be failures for that reason. > > Perhaps it's because the "Message" in OO systems is often forgotten: message > passing is described as "calling a method", instead of "sending a message". > > Many languages do not reify the message itself as an object. > > 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() > > Tort does this, so does MOS ( > http://kurtstephens.com/pub/mos/current/src/mos/ ), however Ruby, for > example, does not -- not sure how many others do. > > The Self Language handles apply() by cloning the method object, assigning > arguments into its slots, then transferring control to the object's code > slot. Yet, there is still no tangible Message object. >
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? 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? 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? >> It's very difficult to use OO in this way without imposing excessive >> knowledge about the internal representation of objects if you need to >> serialize parameters or response objects. >> > > Remembering there is an implicit Message object behind the scenes makes > message distribution a bottom-up abstraction, starting with identity > transforms: > > http://kurtstephens.com/pub/abstracting_services_in_ruby/asir.slides/index.html > > This doesn't fully remove the serialization issues, but those are readily, > and often already, solved. One generic serialization is suitable for the > parameters and the message objects; decomposed into Request and Response > objects. The Transport is then agnostic of encoding/decoding details. > >> HTTP seems to have avoided this by using MIME types, but this is more >> about agreed upon engineering standards rather than computational >> abstractions. >> > > I'm not a fan of HTTP/SOAP bloat. The fundamentals are often bulldozed by it. How about REST? > >> Cheers, >> Steve >> > > -- Kurt _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
