3 ms·

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 environ

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.

em-bee 5y ago
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.

em-bee 5y ago

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.