allow other code to arbitrarily call-in and out of Smalltalk
why not? isn't that the property of any RPC interface? can't RPC be completely language agnostic? as far as i understand this all depends on how flexible the RPC interface is.
i have certainly seen RPC interfaces in high level languages that allow me to call any object or function in the target system. in fact, i am working with a platform written in pike that has such an interface. pike is a high level language like python or smalltalk, and the RPC interface of this platform has clients in java and php where i can access server side objects as if they were part of the client. like i could with CORBA or others.
there is no reason why smalltalk could not support something similar.
CORBA and DCOM both expose an endpoint to allow remote systems to access a specific remote environment. You could run two or more distinct CORBA or DCOM environments on a single remote host (which may or may not use the “same” objects, e.g. singletons). Even with a single remote environment you still need to set it up (COM+ MMC snap-in, anyone?), and the problem with having a setup process is the point of my comment: calling from arbitrary program into a Smalltalk program requires that Smalltalk environment to already exist somewhere - or for that entry point you’re calling-into to be responsible for setting-up and tearing-down that environment when it returns. Stuff like this is both context-sensitive and non-trivial.
For example, assuming that multiple entrypoints can share a lazily-initialised singleton environment then how should concurrent calls into the environment be handled? What about asynchronous callbacks? And so on.
Or more generally: “How can Smalltalk be integrated into an existing - or new - non-Smalltalk system?” - and it seems to me the answer is “it’s complicated” and not as simple as invoking a thread-safe C-style export that’s automatically generated by the Smalltalk toolchain.
i think there are two concepts being mixed here, and i am not quite sure how you relate the two:
if i understand you correctly then you seem to suggest that embedding smalltalk into a c environment is not trivial because smalltalk has its own runtime.
that is something that i agree with. but here is my confusion: how is that different from CORBA? doesn't that also just allow connecting two distributed runtime systems?
so my understanding is that it would be possible to have a c<->smalltalk bridge just like CORBA, (and that's the same kind of bridge in the pike based platform i mentioned between java/php<->pike) but both are different from embedding smalltalk outright.
all that said, from what i understand objective-smalltalk is something different entirely, it is a smalltalk environment with an objective-c based runtime, more like clojure or other languages on top of java.
why not? isn't that the property of any RPC interface? can't RPC be completely language agnostic? as far as i understand this all depends on how flexible the RPC interface is.
i have certainly seen RPC interfaces in high level languages that allow me to call any object or function in the target system. in fact, i am working with a platform written in pike that has such an interface. pike is a high level language like python or smalltalk, and the RPC interface of this platform has clients in java and php where i can access server side objects as if they were part of the client. like i could with CORBA or others.
there is no reason why smalltalk could not support something similar.