In Smalltalk, calling a method is what the system does after a message is sent and the system looks up the receiver and its class hierarchy. This is a little d

In Smalltalk, calling a method is what the system does after a message is sent and the system looks up the receiver and its class hierarchy. This is a little different from C++ where the message dispatch is just vtable lookup by the calling code, because the system might have different behavior, such as changing the message to a #doesNotUnderstand: message. However, in your question it is not much different because the default approach is synchronous. Yes, the calling process waits for the receiver to send a response. This has been one of the sticking points of remoting objects since the beginning, that you cannot treat the network as completely transparent. The options are the same as in other languages: promises, callbacks, forking a process, etc. On the other hand, having a simple representation for network calls that the runtime can figure out for you automatically is pretty cool. You can ask Smalltalk to create proxies on the fly that act like the real thing but do the marshalling and network calls. The same was true for RMI in Java, which may have been based on Smalltalk and/or Modula-3. Comparing this to COM or CORBA, where the representation is defined externally, or to SOAP or some JSON api, where all bets are off, keeping everything in one system makes this stuff easy.