3 ms·
This reminds me, for some reason even though it's totally different, of NeXT's Distributed Objects facility, which I think is still floating around OS X but am
by SeanLuke 15y ago
This reminds me, for some reason even though it's totally different, of NeXT's Distributed Objects facility, which I think is still floating around OS X but am not sure. Here's how it worked.
In Objective-C, method calls are dynamically bound. So you can make the following call:
[myObject crazyMethodName:x:y:z]
In Java that'd be myObject.crazyMethodName(x,y,z)
However unlike Java, there doesn't have to be a method called crazyMethodName, and the compiler will still compile it just fine. What happens is that at runtime, when this method is called, the message "crazyMethodName" is sent to myObject. If it doesn't have a method which responds to that name, then Objective-C calls the "forward" message on myObject, passing in the "crazyMethodName" method name and the arguments. "forward" can do what it likes with this -- the default implementation of "forward" is (was?) to issue a No Such Method Found error.
What Distributed Objects did was create a special proxy object which has a single method implemented: "forward". The system worked as follows. When machine A connects to machine B, machine B gives machine A its "entry" object (as defined by the user). B thinks it gave A an object, but in fact what A received was a proxy object. Let's say that the entry object responds to a method "foo". A calls
[obj foo]
obj is actually a proxy which responds to no methods at all, except for "forward". Objective-C fails to call "foo" on obj, so it tries "forward", and lo and behold the proxy has implemented that in a special way -- it wraps up the method call and ships it over to machine B and calls "foo" on the real object.
Through this procedure objects get passed as arguments back and forth through these method calls, which in turn wind up generating more and more proxies. Ultimately neither machine knows that the objects it's got access to are fakes. It just feels like you've been given access to call and manipulate another processes objects. Very clean and elegant.
- zrail 15y agoI wonder if this inspired DRb[1]. It sounds very similar. The biggest problem is that it's synchronous even across machine boundaries. Celluloid and Dcell[2] are the same basic idea but more explicit. [1]: http://segment7.net/projects/ruby/drb/introduction.html http://segment7.net/projects/ruby/drb/introduction.html [2]: http://www.unlimitednovelty.com/2011/05/introducing-celluloid-concurrent-object.html http://www.unlimitednovelty.com/2011/05/introducing-celluloi...
- krevis 15y agoNo idea why this reminded you of DO -- as you say, it's a totally different thing. DO still works in OS X. Frankly, it's a neat hack, but it's prohibitively difficult to build anything robust on top of it: - Error handling is difficult -- what happens when the other side goes down in the middle of your method call? If you have to add extra exception and timeout handling everywhere, that dwarfs the small convenience of making the dispatch code easy. - Hard to make it secure. - It's impossible to interoperate with anything else -- what happens when you want to talk to your DO-based server using Java or Windows or Linux? See "A Note On Distributed Computing" from 1994 for more caveats on this whole approach: http://labs.oracle.com/techrep/1994/abstract-29.html http://labs.oracle.com/techrep/1994/abstract-29.html